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

【问题标题】：Add managed DLL dependencied to unmanaged C++ project将依赖的托管 DLL 添加到非托管 C++ 项目
【发布时间】：2016-12-12 02:32:32
【问题描述】：

我有托管 DLL A.dll 的项目，它依赖于托管 B.dll 和 C.dll。

我通过 COM 接口向非托管 C++ 项目 D 公开 A.DLL。一切都好...但是 A.DLL 找不到 D.dll 和 C.dll 并引发适当的异常。我尝试将它们放在同一个文件夹中，但它不起作用。我应该如何以及在哪里引用这些依赖项？

在 C++ 中，我只会使用静态链接构建 A.dll，但 .NET 没有此选项。

更新：将库放在与 .exe 文件相同的目录中有效，我只是丢失了我的二进制文件。

【问题讨论】：

A如何“依赖B”？它是正常的.NET 参考吗？你有一个小的复制项目吗？
@SimonMourier 是的，这是一个普通的.Net 参考。例如，它依赖于 Nuget 的 Newtonsoft.Json。我明天可以发布复制项目。

标签： c# c++ .net dll com

【解决方案1】：

正常的 CLR 搜索规则适用于此。它首先在 GAC 中查找，然后在 EXE 所在的目录中查找。您可以说服 COM 运行时从注册中找到 A.dll，它可以存储在 Regasm.exe /codebase 选项告诉它查找的任何位置。但这确实不影响 CLR 查找依赖项的位置，它只考虑 EXE 位置。

您可以使用 Fuslogvw.exe 实用程序解决此问题。

替代方案通常很麻烦。只要您在 A.dll 中有一个保证首先实例化的 [ComVisible] 类型（想想“应用程序”），那么您就可以在构造函数中订阅 AppDomain.CurrentDomain.AssemblyResolve 事件，以帮助 CLR 定位其他 DLL。但是很重要的是构造函数不需要来自 B 或 C 的类型，当抖动需要它们来编译构造函数时，你仍然会崩溃。

如果这不是一个合适的选项，那么如果您更喜欢将 DLL 部署在 EXE 安装目录的子目录中，那么编写一个 appname.exe.config 文件可能会有些用处。然而，这在 COM 场景中很少是一个好主意，因为您通常无法控制 EXE，这通常是其他人的责任。测试代码时，本地部署很好。对于生产部署，您应该认真考虑 GAC。总的来说，在 COM 中无论如何都是一个好主意，因为注册是机器全局的，这给它带来了强大的 DLL Hell 头痛。

【讨论】：