How to resolve .NET dependency of COM component?

Question

This is my current deployment scenario:

• Client application is deployed in folder A
• COM DLL, C++/CLI wrapper DLL and .NET assembly are deployed in folder B
• DLLs/assemblies together form an SDK, the client application is a third-party consumer

This is how it is supposed to work:

• Client application starts and creates COM object
• Client application calls function in COM object
• COM Object forwards call to C++/CLI wrapper DLL
• C++/CLI wrapper function forwards call to .NET assembly

The problem: The C++/CLI wrapper cannot find the .NET assembly and the application crashes.

Solutions I can think of so far:

• Give the .NET assembly a strong name and deploy it to the GAC instead of to folder B
• Give the client application a .config file and tell it to look for assemblies in folder B
• Add some sort of custom "resolver routine" to the C++/CLI wrapper that dynamically loads the .NET assembly (something like this SO answer)

For various reasons none of these solutions seem particularly attractive. Do you know of any other mechanism how this problem can be solved? The ideal solution would use some sort of configuration on the SDK side, but as far as I know it is not possible to give assemblies a .config file, or is it?

As I am not particularly .NET savvy, I would also be grateful for comments on the "resolver routine" solution. Is this something that people routinely do, or is it something exotic that should be avoided for some reason?

Answer 1

In my mind, what you called the "resolver routine" is the best solution. Since your assembly is loaded into the default context, the search paths contains the client application current folder, not the folder of the assembly. Rearding this article, this is a typical case for using AppDomain.AssemblyResolve event. I guess you can either load your assembly into a custom context but it sounds a bit too much to me (just my two cents)

I hope this helps