Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

like image 626
ck. Avatar asked Feb 12 '10 15:02

ck.


People also ask

Where does .NET look for assemblies?

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 in .NET framework?

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.

How do you fix referenced assembly does not have a strong name error?

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.

How is a strongly named assembly different from one that isn't strongly named?

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.


1 Answers

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

like image 194
bryanjonker Avatar answered Oct 10 '22 02:10

bryanjonker