如何解决COM组件的.NET依赖？

Question

这是我目前的部署方案：

• 客户端应用程序部署在文件夹A
中
• COM DLL，C ++ / CLI包装器DLL和.NET程序集部署在文件夹B
中
• DLL /程序集一起形成SDK，客户端应用程序是第三方消费者

它应该如何运作：

• 客户端应用程序启动并创建COM对象
• 客户端应用程序调用COM对象中的函数
• COM对象转发对C ++ / CLI包装器DLL的调用
• C ++ / CLI包装函数转发对.NET程序集的调用

问题：C ++ / CLI包装器找不到.NET程序集，应用程序崩溃。

到目前为止我能想到的解决方案：

• 为.NET程序集提供强名称，并将其部署到GAC而不是文件夹B
• 为客户端应用程序提供.config文件并告诉它在文件夹B中查找程序集
• 将某种自定义“解析程序例程”添加到动态加载.NET程序集的C ++ / CLI包装器（类似this SO answer）

由于各种原因，这些解决方案似乎都没有特别吸引人。你知道如何解决这个问题的任何其他机制吗？理想的解决方案是在SDK端使用某种配置，但据我所知，不可能为程序集提供.config文件，或者是它？

由于我不是特别精通.NET，我还要感谢对“解析程序例程”解决方案的评论。这是人们经常做的事情，还是因某种原因应该避免的异国情调？

Answer 1

在我看来，你所谓的“解析程序”是最好的解决方案。由于您的程序集已加载到默认上下文中，因此搜索路径包含客户端应用程序当前文件夹，而不是程序集的文件夹。 等待this article，这是使用AppDomain.AssemblyResolve事件的典型案例。 我想你可以将你的程序集加载到自定义上下文中，但对我来说听起来有点太多了（只是我的两分钱）

我希望这会有所帮助