我有托管DLL A.dll的项目，它依赖于托管的B.dll和C.dll .
我通过COM接口将A.DLL暴露给非托管C项目D.一切都还可以......但A.DLL找不到D.dll和C.dll并提出适当的例外 . 我尝试将它们放在同一个文件夹中，但它不起作用 . 我应该如何以及在何处引用这些依赖项？
在C中我只使用静态链接构建A.dll但.NET没有此选项 .
Update: 将库放在与.exe文件相同的目录中，我只是丢失了我的二进制文件 .
正常的CLR搜索规则适用于此处 . 它首先查看GAC，然后查看EXE所在的目录 . 您可以说服COM运行时从注册中找到A.dll，它可以存储在Regasm.exe / codebase选项告诉它的任何位置 . 但这确实会影响CLR查找依赖项的位置，它只考虑EXE位置 .
您可以使用Fuslogvw.exe实用程序对此进行故障排除 .
替代方案通常很麻烦 . 只要你在A.dll中有[ComVisible]类型保证首先被实例化（想想“应用程序”），那么你可以在构造函数中订阅AppDomain.CurrentDomain.AssemblyResolve事件，以帮助CLR找到其他DLL . 但是构造函数不需要B或C类型是非常重要的，当抖动需要它们来编译构造函数时，你仍然会崩溃 .
如果这不是一个合适的选项，那么如果您更喜欢在EXE安装目录的子目录中部署DLL，那么编写appname.exe.config文件会有所帮助 . 然而，在COM场景中，这通常不是一个好主意，因为您通常无法控制EXE，这通常是别人的责任 . 在测试代码时，本地部署很好 . 对于 生产环境 部署，您应该认真考虑GAC . 总的来说，无论如何COM中的一个好主意，因为注册是机器全局的，这给它带来了强大的DLL Hell头痛 .
1 回答
正常的CLR搜索规则适用于此处 . 它首先查看GAC，然后查看EXE所在的目录 . 您可以说服COM运行时从注册中找到A.dll，它可以存储在Regasm.exe / codebase选项告诉它的任何位置 . 但这确实会影响CLR查找依赖项的位置，它只考虑EXE位置 .
您可以使用Fuslogvw.exe实用程序对此进行故障排除 .
替代方案通常很麻烦 . 只要你在A.dll中有[ComVisible]类型保证首先被实例化（想想“应用程序”），那么你可以在构造函数中订阅AppDomain.CurrentDomain.AssemblyResolve事件，以帮助CLR找到其他DLL . 但是构造函数不需要B或C类型是非常重要的，当抖动需要它们来编译构造函数时，你仍然会崩溃 .
如果这不是一个合适的选项，那么如果您更喜欢在EXE安装目录的子目录中部署DLL，那么编写appname.exe.config文件会有所帮助 . 然而，在COM场景中，这通常不是一个好主意，因为您通常无法控制EXE，这通常是别人的责任 . 在测试代码时，本地部署很好 . 对于 生产环境 部署，您应该认真考虑GAC . 总的来说，无论如何COM中的一个好主意，因为注册是机器全局的，这给它带来了强大的DLL Hell头痛 .