Hi,

My question is related to understanding the loading of assemblies of a .Net executable. The part that is eluding me is the mixture of assemblies that are Referenced by the Visual Studio project and the Dependent assemblies of the one assembly I am dynamically loading by my Class Factory at runtime. The Class Factory method is loading my dynamic assembly from another folder than the executable and its dependent assemblies.

Here is a sample:

• Folder1 -> TestProgram.exe Dependent1.dll Dependent2.dll ClassLoaderFactory.dll

• Folder2 -> DynamicAssembly.dll DynamicDependent1.dll DynamicDependentXMLSerializer.dll

So, TestProgram starts and needs a class from DynamicAssembly.dll, so it asks ClassLoaderFactory.dll to give it the Class (Interface). ClassLoaderFactory loads the DynamicAssembly.dll, gets the Class and returns it. It seems like DynamicDependent1.dll gets loaded in the executable, because I can look with ProcExp and see it loaded. But, there are some funky exceptions happening inside of DynamicDependent1.dll, to which I don't have access to because it is a 3rd party assembly. (If I statically load all of these (Without the ClassFactory), everything works fine.) ProcExp shows the DynamicDependent1.dll getting loaded from Folder2 as expected.

While trying to narrow this down, I put a copy of DynamicDependent1.dll in Folder1 (along side of the executable) and ran the program again and then everything worked fine. ProcExp showed that DynamicDependent1.dll got loaded from the Folder1 where the executable was.

There is no direct relationship or dependency between the executable and DynamicDependent1.dll, so why did the CLR opt to grab it there instead of Folder2?

Another quirk, which could be related, but I'm not sure, the assembly DynamicDependentXMLSerializer.dll is not referenced but does exist and does not get loaded at all. I put a currentDomain.AssemblyResolve Event handler in place and can see that it is being asked for, so I manually loaded it in the handler and could see that it was loaded, looking at ProcExp. But that did not make any difference to getting the exception or not.

Any suggestions would be welcome!

Thanks

Yeah this is confusing and I don't exactly recall how this works. If I remember right, .NET always looks in the private bin folder first, then if it can't find it there looks in the same folder as the dll.

So even if you load an assembly out of folder 2 and it has a dependency on another assembly in folder 2 it will look in the private bin folder first, then and only then in the same folder the assembly was loaded from.

If the assembly was previously loaded it won't load again of course.

+++ Rick ---

Thanks for the reply and for your excellent forum. While researching this whole project, your blogs and forums had the most useful and accurate information in them!

The resolution in this case came down to a blunder on my part. My Class factory that loaded the dynamic dll got called twice, so it loaded the dynamic dll twice (Assembly.Load()) and called the Activator.CreateInstance(objectType) twice. Apparently the CLR didn't know how to keep the dependencies straight because of that. Once I resolved that issue everything worked the same as when it was built with static dependencies.

My faith in understanding some of the workings of .Net has been restored again. But.... tomorrow is another day.

Wow, .Net is so spiteful... I guess it is not resolved (I couldn't even have confidence for one day.), I just found that the dll which I had put in the folder with the executable had gotten back in there again, which made the program work properly. So, the multiple loads of the dll didn't make any difference.

The issue still comes down to if the DynamicDependent1.dll gets loaded from the folder where the executable is located, the program works. If it gets loaded from the folder where the other dynamic dlls are located, it does not work.

Anyway, just wanted to update this thread so it doesn't have misleading information. (Confusing and open-ended, still...)