我继承了一个unmanmanged DLL（最初是用C代码构建的），并希望在.NET项目中使用它。我有头文件将DLL的功能包装在C ++类型对象中，这是我想要公开的面向对象的功能。当我在标准C ++（Win32）项目和C ++ / CLI项目中#include这些头文件时，一切正常，引用原始DLL。
使用Visual C ++ Express 2010，我尝试为.NET构建托管DLL。然后，由于依赖性问题，此DLL在运行时崩溃。依赖步行者说：
警告：找不到至少一个延迟加载依赖模块。
警告：由于延迟加载相关模块中的导出功能缺失，至少有一个模块具有未解析的导入。
并抱怨找不到gpsvc.dll或ieshims.dll。我知道这与x86 vs x64（我在x64上运行Win7）有关，但是，因为我可以在我的系统中使用C ++项目中的DLL，我怀疑它必须可以将它包装在托管DLL中以供使用在.NET上的同一系统上。
非常感谢能够提供任何见解的任何人！
（顺便说一句，我的目标是开发一个.NET程序集，而不是直接在原始DLL上使用p / invoke，因为很多C＃/ VB程序员会在我之后使用有限的互操作经验）< / p>
答案 0 :(得分：0)
解决方案：x86 / x64问题是一个红色的鲱鱼。我有一个三连胜的长链依赖。 Visual Studio的所有引用的“复制本地”属性设置为true，因此我引用的托管dll是本地复制的，远离其依赖项。
出于某种原因，我无法弄清楚，将引用的copy local属性设置为false并删除它所做的本地副本并不能解决问题。我不得不将依赖项复制到C＃项目的本地bin。
一个潜在的问题是，过多关注依赖性walker中缺少的调用时依赖性可能会导致你走向错误的方向。
答案 1 :(得分：0)
正如您所说，Rory，在您的回答中提到，解决方案似乎是您需要在C＃应用程序的References部分中包含所有依赖DLL /手动包含C＃bin中的所有DLL或者与C＃bin相同的文件夹。 exe正在运行。
我刚刚遇到了与您类似的设置问题。我有以下依赖项：
C# application -> (1) CLI Wrapper DLL -> (2) C++ Wrapper DLL -> (3) 3rd Party DLL
在References部分中，我包含了（1）CLI DLL。我没有包含（2）C ++ DLL，因为它抛出错误ERROR ...could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component（解释：C ++ DLL不符合.NET / CLR）。
然后我假设因为（1）CLI DLL正确且成功地链接到（2）C ++ DLL （我用C ++ / CLI控制台应用程序测试过）， C＃应用程序将能够通过引用的（1）CLI依赖项访问（2）C ++依赖项。这是不正确的。
我不知道原因，但C＃应用程序无法访问CLI的依赖项。
我的解决方案是在.exe的目录中手动包含（2）C ++ DLL。请记住，如果Local Copy设置为true，则自动复制（1）CLI DLL C＃应用程序。我似乎没有遇到（2）引用（3）第三方DLL的C ++ DLL的任何问题（即（3）第三方DLL可以驻留在其指定的路径中/不需要在本地复制）。