将依赖的托管DLL添加到非托管C ++项目

Question

I have project with managed DLL A.dll which depends on managed B.dll and C.dll.

I expose A.DLL to unmanaged C++ project D via COM interface. Everything is okay... But A.DLL can't find D.dll and C.dll and raises appropriate exception. I tried putting them in the same folder but it does not work. How and where should I reference those dependencies?

In C++ I would just build A.dll with static linking but .NET does not have this option.

Update: putting library in the same directory as .exe file works, I just lost my binary.

Answer 1

Normal CLR search rules apply here. It first looks in the GAC and next looks in the directory in which the EXE is located. You can convince the COM runtime to locate A.dll from the registration, it can be stored anywhere the Regasm.exe /codebase option tells it to look. But that does not affect where the CLR looks for dependencies, it only considers the EXE location.

You can troubleshoot this by using the Fuslogvw.exe utility.

Alternatives are in general troublesome. As long as you have a [ComVisible] type in A.dll that's guaranteed to be instantiated first (think "Application") then you can subscribe the AppDomain.CurrentDomain.AssemblyResolve event in the constructor to help the CLR locate the other DLLs. But it is very important the constructor doesn't need types from B or C, you'll still crash when the jitter needs them to compile the constructor.

If that's not a suitable option then writing an appname.exe.config file can be somewhat useful if you prefer deploying the DLLs in a subdirectory of the EXE install directory. This is however rarely a good idea in a COM scenario since you are typically not in control over the EXE, it is usually somebody else's responsibility. Deploying locally is fine when you test your code. For production deployment you ought to seriously consider the GAC. In general a good idea in COM anyway since registration is machine-global which gives it strong DLL Hell headaches.