How to determine where Assembly.Load () is looking for assemblies?

Question

I have a VS add-in that uses a BinaryFormatter to deserialize an object. To enable the type of this object, it calls Assembly.Load (objectTypeFullName), but it throws an exception because Assembly.Load cannot find the assembly in any of the places where it runs. This assembly refers to the assembly, but it seems that Assembly.Load () cannot find it there.

A possible solution would be to determine where Assembly.Load should look for assemblies.

What should I do?

PS: I try not to put this assembly in the GAC because I will need to update it every time I recompile the assembly.

Answer 1

You can use AppDomainSetup.PrivateBinPath to add additional private search paths. This can be obtained using AppDomain.SetupInformation .

Another option is to sign up for AppDomain.AssemblyResolve to override the behavior when it could not find your assembly.

Answer 2

Here's a snippet of code showing how AssemblyResolve can be used to solve your assembly (according to Reed Copey):

// register to listen to all assembly resolving attempts: AppDomain currentDomain = AppDomain.CurrentDomain; currentDomain.AssemblyResolve += new ResolveEventHandler(MyResolveEventHandler); // Check whether the desired assembly is already loaded private static Assembly MyResolveEventHandler(object sender, ResolveEventArgs args) { string desiredAssmebly = args.Name; if (desiredAssembly.Equals("NameUsedToLoadMyAssembly")){ return Assembly.LoadFrom(myAssemblyPath); } return null; } 

Also note that the MSDN page for AssemblyResolve states that:

Starting with the .NET Framework version 4, the ResolveEventArgs.RequestingAssembly property returns the assembly that requested the assembly, which might not have resolved ...

This can be used if you know your assembly location compared to the assembly request.

Answer 3

If you are just trying to determine where the assembly loader is trying to load your dll, I recommend that you enable merge logs. This will allow you to get an output that will show you every path that has been checked for the corresponding DLL.

There is an MSDN article on setting up merge logs and a useful Suzanne Cook article on how to debug boot errors. If you enable LogFailures , and you should get output for assemblies that have not been downloaded.