How does the .NET Runtime Locate Non Strong-Named' Assemblies?

Question

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.

Percheron

It cannot possibly work the way you describe it. There's no way for the CLR to find a DLL in the LAC subdirectory without altering the probing path. – Fanaticize

What is your purpose to have two different versions of an assembly that looks the same from here? Can't you just load the latest for you application to work? – Ogawa

There are 2 different versions because the application consists of different plugins written by different teams, each of which could be using a different version of the assembly. Typically, we just use the highest version via a probing path/binding redirect. But I just wanted to know if the CLR does/doesn't disregard versioning for non strong-named assemblies. – Percheron

Answer 1

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 :-).

Octangle