Ok so I have a pretty unique problem here. I'm getting an error basically because I'm referencing the latest version of a dll which I still want to keep references to by default because most of the code in my project is supposed to be using this dll. The error occurs because it's trying to use an object that is only available in the older version of the dll. So I want to use this older version of the dll for this particular section of code. I have tried to load this older version of the dll using Assembly.LoadFrom(pathToAssembly) but it still appears to reference the newer version of the dll. Does anyone have any ideas on how I can replace the reference to this dll to the older version?
Only real option you have is to make sure that assembly is strongly signed, make sure there is no assembly binding redirect to newer version and than manually (with Assembly.LoadFrom) load second version into your appDomain. This way code will be able to use precise version of assembly and both assemblies can be loaded into same appDomain at the same time.
Note that this will lead to complete nightmare if you ever need to pass references to such objects between pieces of code linked against different assemblies.
If you want extra painfun - load both assemblies from bytes and use reflection to construct types for each version...
I'd strongly recommend avoiding all the pain by loading code using different versions of assembly to at least separate appDomains, but preferably to separate processes. If you still decide to take adventurous path of loading multiple versions of assembly to same appDomain make sure to read all aassembly loading blog post from https://blogs.msdn.microsoft.com/suzcook/2003/09/19/loadfile-vs-loadfrom/
Related
I have a project that uses System.Runtime.Serialization assembly. I am using the type DataContractSerializer from that assembly, but I have a problem.
There are two assemblies:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Runtime.Serialization.dll
C:\Windows\Microsoft.net\Framework\v4.0.30319\System.Runtime.Serialization.dll
Both of them have the same version - v4.0.30319. The first one have 429kb size, and the second one 1037kb. I used reflector to see the list of classes, and the first one doesn't have the class that I need (DataContractSerializerSettings). However, the second one does have it.
Why are there some big difference in size and classes for that assembly? Will it be ok, if I use the second one, instead of the first?
.NET version 4.0 made a big change in the way framework reference assemblies are done. Previously, the reference assembly was a simple copy of the runtime assembly, the one stored in the GAC. That however caused some painful problems. Notable is the WaitHandle.WaitOne(int) overload, it was added in the .NET 2.0 Service Pack 2 update (aka .NET 3.5). Programmers used it without noticing that it was an added method, the mscorlib assembly version number was still 2.0.0.0. But then discovered their program failed when running on an unpatched version of .NET 2.0. Very nasty kaboom, MissingMethodException without a hint why such a common method could be missing.
To prevent this kind of breakage, the .NET 4.0 reference assemblies are kept separate, in the "%programfiles%\Reference Assemblies" directory as you found out. And they are special assemblies, they only contain the metadata with all the IL stripped out. Which is why the assembly is so much smaller.
Microsoft now can improve the .NET 4 code and add public classes and methods without causing this kind of breakage. And have done so profusely, updates 4.01, 4.02 and 4.03 have shipped since the original 4.0 release.
The reason you are having trouble with the DataContractSerializerSetting class is thus easily explained, it just doesn't appear in the reference assembly. It got added, probably in one of those incremental updates. And you should not try, your program will break on a machine that doesn't have the update. You should wait until .NET 4.5, the version that added it to the reference assembly. You can invoke DLL Hell if you really want to.
I'm working on a .net project, which is using third party .net DLLs. Some of this DLLs are using common DLLs (e.g. Microsoft.Practices.EnterpriseLibrary.Logging). Now we want to use the same common DLLs in a newer version. We are not allowed to use the GAC (politics).
We have separated the parts in different directories.
Third party \ Third party.dll
old common (Microsoft.Practices.EnterpriseLibrary.Logging.dll)
Our libs \ our lib.dll
new common (Microsoft.Practices.EnterpriseLibrary.Logging.dll)
Surprise, Surprise, it did not work. In our dll an error is thrown saying, some option is not valid. Yes, I did not find it in the old common, but in the new. So, I guess, the wrong executable was taken.
In Visual Studio (2015) we have enabled the "Spezific Version" in the reference, and in the Debug / module windows, both DLLs are loaded.
Edit: All Dlls have strong names.
How do I determine which DLL was executed (stepping with F11 just jump to the catch block)? How do I force using the correct DLL?
(The architecture loads first the third party DLL, then our own dll. This is not changeable without a few years rewriting...)
You can use assembly binding redirects and hope the universe doesn't break (there's no guarantee the newer DLL is backward compatible) or you can strong name the dlls.
Why? .NET generally does not allow you to load the "same" assembly more than once in the same AppDomain, unless it is strong-named. What's strong naming? It is a form of identity and digital signing that consists of:
Assembly filename
Assembly version
Assembly culture
Assembly public key
When it's strong-named, both dlls run side-by-side in the same AppDomain within the same process with perfect backward compatibility.
Alternatively if you don't want to use strong-naming (because many files may require signing) or binding redirects, you can always create additional AppDomains and load a version of the dlls into each domain.
Though it gets around the problem of fiddling with files, it does require considerable rework of the rest of the app making it an arguably bad choice at this point in your development.
EDIT: I see now you are using strong names on both.
How do I force using the correct DLL
To distinguish between the two types in the exact same namespace, you might have to create an alias for the newer assembly in your dll reference. Tell me more...
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.
Since version 3.0, .NET installs a bunch of different 'reference assemblies' under C:\Program Files\Reference Assemblies\Microsoft...., to support different profiles (say .NET 3.5 client profile, Silverlight profile). Each of these is a proper .NET assembly that contains only metadata - no IL code - and each assembly is marked with the ReferenceAssemblyAttribute. The metadata is restricted to those types and member available under the applicable profile - that's how intellisense shows a restricted set of types and members. The reference assemblies are not used at runtime.
I learnt a bit about it from this blog post.
I'd like to create and use such a reference assembly for my library.
How do I create a metadata-only assembly - is there some compiler flag or ildasm post-processor?
Are there attributes that control which types are exported to different 'profiles'?
How does the reference assembly resolution at runtime - if I had the reference assembly present in my application directory instead of the 'real' assembly, and not in the GAC at all, would probing continue and my AssemblyResolve event fire so that I can supply the actual assembly at runtime?
Any ideas or pointers to where I could learn more about this would be greatly appreciated.
Update: Looking around a bit, I see the .NET 3.0 'reference assemblies' do seem to have some code, and the Reference Assembly attribute was only added in .NET 4.0. So the behaviour might have changed a bit with the new runtime.
Why? For my Excel-DNA ( http://exceldna.codeplex.com ) add-in library, I create single-file .xll add-in by packing the referenced assemblies into the .xll file as resources. The packed assemblies include the user's add-in code, as well as the Excel-DNA managed library (which might be referenced by the user's assembly).
It sounds rather complicated, but works wonderfully well most of the time - the add-in is a single small file, so no installation of distribution issues. I run into (not unexpected) problems because of different versions - if there is an old version of the Excel-DNA managed library as a file, the runtime will load that instead of the packed one (I never get a chance to interfere with the loading).
I hope to make a reference assembly for my Excel-DNA managed part that users can point to when compiling their add-ins. But if they mistakenly have a version of this assembly at runtime, the runtime should fail to load it, and give me a chance to load the real assembly from resources.
To create a reference assembly, you would add this line to your AssemblyInfo.cs file:
[assembly: ReferenceAssembly]
To load others, you can reference them as usual from your VisualStudio project references, or dynamically at runtime using:
Assembly.ReflectionOnlyLoad()
or
Assembly.ReflectionOnlyLoadFrom()
If you have added a reference to a metadata/reference assembly using VisualStudio, then intellisense and building your project will work just fine, however if you try to execute your application against one, you will get an error:
System.BadImageFormatException: Cannot load a reference assembly for execution.
So the expectation is that at runtime you would substitute in a real assembly that has the same metadata signature.
If you have loaded an assembly dynamically with Assembly.ReflectionOnlyLoad() then you can only do all the reflection operations against it (read the types, methods, properties, attributes, etc, but can not dynamically invoke any of them).
I am curious as to what your use case is for creating a metadata-only assembly. I've never had to do that before, and would love to know if you have found some interesting use for them...
If you are still interested in this possibility, I've made a fork of the il-repack project based on Mono.Cecil which accepts a "/meta" command line argument to generate a metadata only assembly for the public and protected types.
https://github.com/KarimLUCCIN/il-repack/tree/xna
(I tried it on the full XNA Framework and its working afaik ...)
Yes, this is new for .NET 4.0. I'm fairly sure this was done to avoid the nasty versioning problems in the .NET 2.0 service packs. Best example is the WaitHandle.WaitOne(int) overload, added and documented in SP2. A popular overload because it avoids having to guess at the proper value for *exitContext" in the WaitOne(int, bool) overload. Problem is, the program bombs when it is run on a version of 2.0 that's older than SP2. Not a happy diagnostic either. Isolating the reference assemblies ensures that this can't happen again.
I think those reference assemblies were created by starting from a copy of the compiled assemblies (like it was done in previous versions) and running them through a tool that strips the IL from the assembly. That tool is however not available to us, nothing in the bin/netfx 4.0 tools Windows 7.1 SDK subdirectory that could do this. Not exactly a tool that gets used often so it is probably not production quality :)
You might have luck with the Cecil Library (from Mono); I think the implementation allows ILMerge functionality, it might just as well write metadata only assemblies.
I have scanned the code base (documentation is sparse), but haven't found any obvious clues yet...
YYMV
Is the following solution the only possibility to use libraries from GAC in code?
Assembly lib = Assembly.Load("MyLibrary, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31f5625abd53197f");
Console.WriteLine(lib.GetType("MyClass").GetMethod("Start").Invoke(obj, null));
I am a little bit confused - I've read quite much about GAC and I know how to sign an assembly, intall and uninstall assembly in GAC, but have no idea how to use it, and how does it help programmers (except that it stores different versions of same library safely). I wish I could normally create classes, not beeing forced to invoke methods presented above.
I don't want any work-arounds such as: "change windows registry" because I don't think GAC was designed for such manipulations. I want a simple answer: what the GAC is for, does runtime environment use it somehow?
What is the point of using GAC, when the code gets really ugly and difficult to manage? Or maybe I am missing something? Maybe I should manually copy an assembly into my local folder? But I heard it's also hard to do.
The GAC is there to help you have multiple versions of your (that's what the public key is for - preventing name clashes) assemblies installed side-by-side, and available to the whole machine, not just your application directory.
So yes, accessing assemblies from the GAC using the version number is pretty much exactly the way the GAC was designed for. ;-)
btw: You should not dynamically load stuff when you don't have to.
IOW: If you already know the class name and assembly version, you could just reference that assembly and skip the rather dramatic performance penalty of not only loading an assembly dynamically, but also invoking methods through reflection. (Instead of e.g. reusing them via interfaces or delegates)
If your assembly has been ngen'ed or GAC'd, then the application will use that automatically, if everything (hashes, etc) matches.
If you reference the assembly in your project, you can use it like a normally referenced DLL that is not in the GAC.