How to load a referenced dll from specified location not GAC

How to load a referenced dll from specified location not GAC?

up vote down vote favorite	I have a dll named A.dll with strong name, another assembly B references A.dll. I place A.dll in c:\myapp, also A.dll is installed in GAC.I hope assembly B loads the A.dll from c:\myapp not GAC. But it always load the A.dll from GAC. My question is how to load a referenced dll from specified local location not GAC.Thanks. .net
	If the assembly in the GAC is actually the same as the one in the local directory, it shouldn't matter where it is loaded from. If they are different, they should probably have different identities; that way, you can reference the specific one you want, and the CLR will be able to differentiate them. –  Kevin Kibler Aug 13 '10 at 4:38 add a comment

up vote down vote

You'll have to give it a different [AssemblyVersion]. Which ultimately makes sense, if the version numbers are the same then there's no reason that the GAC version wouldn't be good. answered Aug 13 '10 at 4:30

I was assuming the assemblies were actually the same in this scenario. If they aren't exactly the same, they should definitely have different identities so the CLR can differentiate them. –  Kevin Kibler Aug 13 '10 at 4:39   Keep it in GAC, because other Apps are using it. Load local A.dll for my App, because I do some change in A.dll, but its version is unchanged, I need the new A.dll for my App. Yes, the trouble is they have the same identity. –  ldlchina Aug 13 '10 at 4:44   If you are doing some change in A.dll, why does the identities remain the same? Just changing the name of the assembly will help solve this situation. –  earlNameless Aug 16 '10 at 12:33 add a comment

up vote down vote

According to the MSDN page about how the CLR loads assemblies, the CLR will load assemblies from the GAC before attempting to load assemblies from the working directory. There doesn't appear to be a way around this. Alternatively, you could just not add the assembly to the GAC so that the CLR would be forced to find the assembly by probing.

Hi, Thanks for reply. I tried configuration file but it still search from GAC first. The search sequence of loading a strong name dll is: 1. GAC 2. The root folder of the app 3. Configuration file I readed the article you provided. 1.Determines the correct assembly version (my case: the version is same as that in GAC) 2.Checks whether the assembly name has been bound to before (my case: No, or how to do?) 3.Checks the global assembly cache (My case: find here, load from GAC) 4.Probes for the assembly (based on the Configuration file) If I misunderstood, please correct me. –  ldlchina Aug 13 '10 at 3:30   I did add configuration file for my App, and the assembly must be added to GAC for some reason. –  ldlchina Aug 13 '10 at 3:46   @jack2000: You're right, configuration files don't appear to help the situation. I removed that section of my answer. –  Kevin Kibler Aug 13 '10 at 4:34 add a comment

up vote down vote

The only way is by using Assembly.LoadFile() to load your assembly. This allows you to specify a path to load. There are several gotchas that make this very painful: You have to do Assembly.LoadFile() before the assembly is loaded automatically None of the dependencies of A.dll are loaded automatically, you will have to load all of them by hand A.dll would not be loaded into LoadFrom context (see msdn for more information), which effectively means any code that references A.dll cannot just use the types from A.dll, you must use reflection

This does not work. Even if you specify the path of the assembly, the CLR will check the GAC and load an equivalent version from there if it exists. –  Kevin Kibler Aug 18 '10 at 1:00 add a comment

up vote down vote	It is possible to do this by hosting the CLR and implementing IHostAssemblyManager and IHostAssemblyStore. This is like using a bazooka to kill a mosquito though.
	add a comment