We have different versions of non strong-named assemblies, and no binding redirects/probing paths to them in app.exe.config. For example, MyDll (1.0.0.0_null_neutral) and MyDll (2.0.0.0_null_neutral). Relative to app.exe, these assemblies are stored in LAC\MyDll_1.0.0.0_null_neutral and LAC\MyDll_2.0.0.0_null_neutral.
My understanding is that because the MyDll assemblies are not strong-named, the .NET runtime doesn't differentiate between different versions of MyDll. Therefore, if MyDll 1.0.0.0 were already loaded into memory and some code that was built against MyDll 2.0.0.0 was executed, the .NET runtime would not load MyDll 2.0.0.0.
However, when I attached to the process with VS2008 and viewed the modules window, I noticed that both MyDll 1.0.0.0 and MyDll 2.0.0.0 were loaded from the LAC folder.
There seems to be a gap in my understanding somewhere. Can someone please point it out?
EDIT: Thanks for the responses so far. Yes, I skipped over that bit. The executable listens to the AssemblyResolve event, and handles it by looking in the LAC.
I was pretty sure I saw some MSDN documentation before that said versions are ignored unless an assembly is strong-named. I'll see if I can dig it up.
The runtime always begins probing in the application's base, which can be either a URL or the application's root directory on a computer. If the referenced assembly is not found in the application base and no culture information is provided, the runtime searches any subdirectories with the assembly name.
What makes a strong-named assembly? A strong named assembly is generated by using the private key that corresponds to the public key distributed with the assembly, and the assembly itself. The assembly includes the assembly manifest, which contains the names and hashes of all the files that make up the assembly.
The solution was to install StrongNamer from NuGet, which automatically adds a strong name to all referenced assemblies. Just simply having it referenced in the project fixed my issue.
Strong naming your assembly allows you to include your assembly into the Global Assembly Cache (GAC). Thus it allows you to share it among multiple applications. Strong naming guarantees a unique name for that assembly. Thus no one else can use the same assembly name.
http://msdn.microsoft.com/en-us/library/yx7xezcf.aspx
Step 2 is checking to see if it's been loaded, and that is version specific, even with items that aren't strongly named.
Step 4 is trying to load the assembly through probing, and this is not version specific.
What I'm confused about is if you don't have any information in your config file, how is it finding the DLL in the first place? I think there's a gap in my understanding as well :-).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With