COM application referenced dlls troubleshooting

Question

I have a WPF application, which I build as a dll COM component and install using installshieldLE, however I have some issues with some dependent dlls, when running my COM client.

My WPF dll references two other C# dlls (A & B) which reside within the same VS2012 solution.

My WPF dll has the register for COM interop option checked and provides a COM interface for running the WPF GUI application.

I have a C COM client program, which tests the WPF application. The problem I am having is that I need to include some of dll_A's referenced dlls, (which is a third party graphics package) in the folder of the client program for the application to run successfully. I don't have to include dll_A or dll_B in the local client directory.

Also, there are other (C) dlls referenced by the COM server dll and included in the installation that do not need to be present in the client directory, so this is difficult to understand.

I assume that this is not a WPF question but simply a question about com server installation in relation to other referenced assemblies.

I have output some debug messages in the primary dlls that confirm that the dlls A&B, along with the main COM dll are being run from the installation location. But I get exceptions further down the line when the third party dlls are missing from the local client folder.

Can someone help me troubleshoot this problem please. I can run the client program successfully from the installation location and am therefore certain that all required assemblies and dlls are present.

Thanks.

Answer 1

It sounds like you're encountering issues related to the DLL load path. A client application can load your COM DLL, but your COM DLL can't load its own dependencies (or dependencies of dependencies, etc) even through the dependencies exist in the same folder as the COM DLL. Is this correct?

If so, I believe this problem can be solved with a call to the AddDllDirectory function -- just have your COM DLL call this before loading any of its dependencies and call RemoveDllDirectory when it's done. For more information, see the Remarks section of the documentation for LoadLibrary.

Answer 2

The problem was caused by one of the referenced dlls being compiled using .Net 4.0, whereas the others were compiled using .Net 4.0 client. Recompiling with .Net 4.0 Client resolved the problem.

The problem seemed to occur when executing the application as a registered com component, with the client being executed from a different location. If the offending dlls were copied to the client directory, everything runs fine.