1

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?

Community
  • 1
  • 1
herzbube
  • 13,158
  • 9
  • 45
  • 87
  • Why the C++/CLI wrapper cannot find the .NET assembly? What's the error? – Simon Mourier May 27 '13 at 21:41
  • @SimonMourier The error is a `FileNotFoundException`. This happens because .NET is looking for assemblies only in folder A (where the application's .exe file is located) and in the GAC. – herzbube May 28 '13 at 07:05
  • In the C++/CLI wrapper, you could hook the AssemblyResolve event: http://msdn.microsoft.com/en-us/library/system.appdomain.assemblyresolve.aspx and point to the .NET assembly when the runtime request it. – Simon Mourier May 28 '13 at 08:30
  • @SimonMourier Yep, that's what the "resolver routine" solution that I mentioned is all about. I have borrowed this - maybe unfortunate - term from the SO answer that I am referencing. – herzbube May 28 '13 at 13:56

1 Answers1

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

loic
  • 185
  • 1
  • 7