assemblies

I have a project that adds some extensibility to another application through their API. However, I want to be able to use the same project for multiple versions of their application, because most of the code is the same. However, each version of the application requires a reference to the proper assembly for that version of the software. They load their assemblies into the GAC, so even if I could specify the version of the assembly to use based on build configuration I would be fine. Is there a way to do this from inside of VS or do I need an external build tool? There is a way to do this, but

What is the difference between Assembly and a DLL? While sending the code to a remote client, should a DLL file be sent or should a Assembly be sent (When direct TCP connection is available between two)? An assembly is .NET's "minimum unit of deployment". Usually an assembly corresponds to a single file, but it doesn't have to - you can have multiple files, with one of them being the master which knows where all the other bits are. Single-file assemblies are usually DLLs or EXE files. If you've got a normal class library and you just want to send it to the other side, the DLL is what you want.

I have a few WPF applications and I want all my styles to be in a shared assembly instead of declaring them in each application separately. I am looking for a way so I don't have to change all my Style="{StaticResource BlahBlah}" in the existing applications; I just want to add the reference to this style assembly, and delete it from the current application, so it's taken from the assembly. Is there any way? Shimmy Referencing an external ResourceDictionary (XAML File): <Application.Resources> <ResourceDictionary Source="MyResources.xaml" /> </Application.Resources> Referencing an external

UPDATE: I now have a solution I'm much happier with that, whilst not solving all the problems I ask about, it does leave the way clear to do so. I've updated my own answer to reflect this. Original Question Given an App Domain, there are many different locations that Fusion (the .Net assembly loader) will probe for a given assembly. Obviously, we take this functionality for granted and, since the probing appears to be embedded within the .Net runtime ( Assembly._nLoad internal method seems to be the entry-point when Reflect-Loading - and I assume that implicit loading is probably covered by

Is there any way to find out if an assembly has been compiled with the TRACE or DEBUG flag set without modifying the assembly? this. __curious_geek The only best way to do is check the compiled assemblies itself. There is this very useful tool called '.NET Assembly Information' found here by Rotem Bloom. After you install this it asociates .dll files to open with itself. After installing you can just double-click on the Assembly to open with it and it will give you the assembly details as displayed in the screenshop below. There you can identify if it's debug compiled or not. alt text http:/

From the description of sn.exe utility and this question I see that a copy of the public key is added to every assembly signed with the strong name. This is enough to validate that the assembly binary has not been altered. But how does one verify that given assembly was really signed with some given keypair and compiled by a given company? Anyone could generate his own keypair, produce some assembly and sign it with his keypair. Do I need to publish the public key so that those who want to verify the assembly origin could compare the public keys? if so, what is the best way to do so? No, you

I'm using Maven and its assembly plugin to build a distribution package of my project like this: one project assembles a basic runtime (based on Felix), with the appropriate directories and bundles, in a ZIP file. third-party libraries are collected in one project each and either converted to OSGi bundles or, if they are already OSGi compatible, they are just copied my own project consists of several modules that are built into OSGi bundles, too. Now, I'm adding another project that unpacks the ZIP, drops all the other JARs into the proper directories, and repackages it for distribution. Now,