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

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 liste开发者_如何学运维ns 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.

---

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