Question

We’re currently developing an add-in for some software. We decided to develop in .NET, even though the application is written in some native language. Since there were some problems directly creating the external interface in .NET, we decided to build a bridge DLL in C++/CLI, which does some basic initialization and then loads our managed assembly and creates a user control from that.

In an add-in .ini file, the C++/CLI DLL is referenced by name, so the application will load it from there. The .NET DLL, however, is just referenced from the C++/CLI DLL (as a managed reference), so the exported types are available. In this setup, howerver, the application crashes loading the .NET DLL.

We quickly found that we could just subscribe to the AppDomain.AssemblyResolve event to load the .NET assembly from the same directory where the C++/CLI DLL is, so the problem itself is solved.

The actual question is: Why doesn’t the loader find the .NET DLL, even though it is in the same directory as the assembly referencing it? I always expected that loading assemblies will first look into the same directory, rather than just into the current working directory. Why does an executable find an assembly if it changes its working directory then? Or are things different if the CLR is invoked by loading a C++/CLI assembly (rather than a pure managed application)?

Answer 1

I would recommend you to use fuslogvw.exe for analyzing problems of this kind:

Fuslogvw.exe and diagnosing .NET assembly binding issues

And, of course, the general purpose tool for analyzing problems with files not found:

Process Monitor