I have .net dll, it use different .net dll with PublicToken set to null. Now I have to use the same version of different dll but with PublicToken set to some other value. Is there a way to use it without a need of recompilation of first dll (I do not have sources).
I don't think there is a clean way of doing this, mainly because what you are trying to do is defeat the very purpose of the Strong Naming concept. bindingRedirect only works on version, not the key. The only way that I can think of is to disable Strong Name Verification:
sn.exe -Vr TheAssembly
You can learn more about that here.
The problem with it is, it has to be done on every machine this is run.
Another alternative is to use a tool like Mono.Cecil to strip the Public Key Token from the Module's Assembly References so it no longer cares. If it is strong named itself, you'd have to remove that too. This option generally works, but will in most cases violate any form of EULA the assembly comes with if it is a commercial product.
Related
Basically, I developped a small library with some common fonctionnalities that I use in all my projects. For some political reasons, I cannot choose a generic name for that library (including namespace and assembly name). Usually, it must include the name of the enterprise, something like this for the namespace: Enterprise.ProjectName.XXX.YYY.
For the moment, I'm doing a copy of my library, then I'm renaming the namespaces manually with Visual Studio, and finally I'm recompiling the whole thing.
So my question is the following: Is it possible to create a small program that takes an assembly as input, rename all namespaces from MyLibrary.XXX.YYY to Enterprise.ProjectName.XXX.YYY as well as the assembly name?
What are the steps to follow?
[Edit]
Generating the assembly automatically seems to much work. I will use resharper and/or CTRL+ALT+F like I did so far. Thanks for the answers...
You could use Mono's Cecil project to disassemble the assembly, inspect each type, rename or recreate the type with a new namespace, and generate the resulting assembly.
That being said, it might be simpler to use a tool like Resharper which allows you to rename namespaces correctly within the code base.
Some options:
If you are copying the entire source code for your library into your new project, you can use a refactoring tool like Resharper to "Adjust Namespaces". This is a pretty quick and safe refactoring.
If you just need to avoid shipping the internally named assembly, you may be able to use ILMerge to 'hide' the internal assembly during a post-build step. This is viable if it's just a perception issue for the final assembly names in the binary output directory.
Deal with the issue at the political level by describing your internal library as being no different from any other third-party dependency. Then the naming is no longer a problem. This may solve other problems if you're shipping the source code of this library to multiple clients, as it clarifies that you are not giving full ownership of your 'shared' code to each client. Otherwise they could potentially argue that you are not allowed to use that 'shared' code in projects for other clients, since it is clearly owned by them, having their enterprise name in the namespace.
I have a MEF-based application which uses adapters to process files. It uses configuration files to determine which directories to watch and which adapter to use to process each type of file. Plugins take the form of a .dll that implements a common interface.
Each .dll requires its own set of dependent libaries. For instance, plugin1.dll might need to use apilibrary.dll and xmllibrary.dll. It is also possible that at a later date I might want to add plugin2.dll, and plugin2.dll might use xmllibrary.dll as well. These dependent libraries are updated regularly, so I can't count on plugin2.dll using the exact same version of xmllibrary.dll used in plugin1.dll.
I'd like to compile each plugin to one .dll file that invisibly includes within itself all of its dependent libraries, which seems like one way to solve this problem. Alternately, I'd like to figure out how each .dll file can look for its dependent libaries in a subfolder, which I believe would also reduce the possibility of versioning conflicts. Or maybe there's a dead simple solution to this problem that I haven't even considered (which is always very, very likely).
Any thoughts?
You should probably try to get this to work with standard .NET loading rules. However, if you do need to control exactly how assemblies are loaded and which versions are loaded, this blog post shows how: Using Loading contexts effectively
I guess you need to weigh up deployability vs. maintenance. The simple solution is to use a tool called ILMerge. ILMerge takes your project output and can take other assemblies and merge them together. This enables you to wrap up all of the assemblies that your plugin is dependent on, and merge them into a single assembly. Optionally you can do things like re-signing with your public key, etc. Here is a good read: Leveraging ILMerge to simplify deployment and your users experience by Daniel Cazzulino.
But while that is good, what happens if a new version of the referenced assembly is distributed that corrects bugs in that which you have embedded? By the rules of Fusions assembly loader, when it loads the types from your referenced assembly, it will see that they have already been loaded, so there is no reason for it to load the updated version. This would then mean you need to recompile your plugin and merge the newer referenced assembly again.
My question would be, is it really that important to ensure a specific version is used? If a newer version provides an updated implementation (that doesn't break backwards compatibility) then surely this should benefit all plugins that need to reference it?
As for as how assemblies are loaded in reference to each other, have a read of Understanding .Net Assemblies and References, which is an invaluable piece of information.
MEF uses standard .NET assembly loading, and everything's loaded in a single AppDomain. You have very little control over how dependencies are loaded - as they just get loaded automatically by the CLR when the assembly is injected via MEF. Normal CLR assembly loading rules apply when using MEF, so dependencies will be loaded as if they were a dependency of your application - no matter where they're located or referenced.
For the most part, if the plugins and their dependencies are properly written, you most likely will not need to worry about this. As long as the versioning in the dependencies is correct, it will likely just work.
So here's the problem. I'm writing some StyleCop plug-in assemblies for use at the company I work for. As such, these assemblies need to reference Microsoft.StyleCop.CSharp.dll for example, which is strongly named.
The problem comes in that if I build this and pass it along to the developers in my group, they must have the same version of the StyleCop dll (currently 4.3.3.0) or it fails to load.
What is the best way to make my add-on rules DLL more independent? Should I just install my 4.3.3.0 version of those subordinate StyleCop dlls in the GAC? Can an assembly (vs an application) use a policy file?
Oh, and one of the main problems is i would like it to work with ANY version of StyleCop the client has installed (or at least 4.3.3.0 or later) if possible.
Many thanks in advance.
Yes you should just install the same version for the other developers. If you do not, you may have unpredictable runtime failures due to changes within StyleCop. Presumably that is why they bothered to increment the version number.
If you don't want to do this, you can configure a different assembly binding in the app.config file. In the config the actual version number which you intend to use at runtime is needed. And yes, this can even be done via policy. But again, I think you are better served by including the correct DLL in the first place.
In your project, go to the properties on the StyleCop reference. Try setting the "Specific Version" property to false.
For various reasons i would rather not use strong named (signed) assemblies in my project. however, one of the projects is referenced by a sharepoint web part which means it must be signed.
is it possible to have this assembly signed but when I reference it from other projects, to do so using a non-strong reference. this would give me the advantages of having a non-signed assembly for the rest of my code but still allow it to be loaded by sharepoint.
The simplest way to do this is probably to have two different project configurations - one of which builds a strongly named assembly and one of which doesn't. Obviously you'll need to be careful how you build and reference the assembly, but that goes with the territory of having conflicting requirements.
Just keep building your project w/o strong names. When you need to deploy it to Sharepoint, use a tool to sign it after it is built. Here's a tool that does exactly that:
http://signer.codeplex.com/Wikipage
You can also do it manually, but it's a PITA:
http://buffered.io/posts/net-fu-signing-an-unsigned-assembly-without-delay-signing/
This is the OP but I don't have an OpenID login so I guess I can't reply as myself.
Thanks for both the responses. I think either would have worked but the situation turned out to be a bit more complex. I've documented my findings here in case anyone else is interested.
In fact sharepoint references assembly A and assembly A in turn references assembly B.
I can build assembly A and B both unsigned with no problem, but then if I want to sign A, I have to change the project itself to reference the signed version of assembly B.
Although there might have been a way to do this, we decided the possible DLL conflicts and configuration control problems with having different sets of DLLs with the same name were not worth the hassle.
So we have decided to sign both these assemblies in all builds, refactoring code into different assemblies where necessary to make sure that only the minimum amount of code is in the signed ones so they are less likely to change.
Tim
Let's assume I have two assemblies:
MyExecutable.dll version 1.0.0
MyClassLibrary.dll version 1.0.0
Now, MyExecutable.dll currently uses MyClassLibrary.dll's classes and methods (which include some algorithms). Most of those algorithms were made on the run, being that later I'll want to refine them if needed. This means, I won't change the interface of those classes but the code itself will see some changes.
The question at hand is, MyExecutable.dll will be expecting MyClassLibrary.dll 1.0.0 and I'll want it to use version 1.0.1 (or something like that). I don't want to have to recompile MyExecutable.dll(because actually there might be more than just one executable using MyClassLibrary.dll). Is there a solution for this problem? I've heard about the GAC, but if possible I'd like to stay away from it.
Thanks
You are looking for Assembly Binding Redirection - this is a configurable way to tell .NET what version assemblies to use.
The first solution is Assembly Binding redirection, already recommended by Oded.
It is advantageous if you have a smaller .dll and want to make something work with its newer versions.
The second option is creating a separate assembly for the interfaces, and referencing only that from the executable.
This way, you can allow third parties to build stuff against your library without giving them the exact library's assembly. (Eg. they can't decompile it with Reflector, so it is more secure this way.)
As long as the interface assembly doesn't change, you can change other stuff in the library pretty much as you want.