无法加载DLL（无法find模块HRESULT：0x8007007E）
我有我需要在.NET 4.0应用程序中使用的非托pipeC ++ API代码的DLL库。 但是，我尝试加载我的DLL的每一个方法我得到一个错误：
无法加载DLL'MyOwn.dll'：无法find指定的模块。 （从HRESULTexception：0x8007007E）
我已阅读并尝试在互联网上find的severa解决scheme。 什么都没有
我曾尝试使用以下方法：
[DllImport("MyOwn.dll", CallingConvention = CallingConvention.Cdecl)] [return: MarshalAs((UnmanagedType.I4))] public static extern Int32 MyProIni(string DBname, string DBuser_pass, string WorkDirectory, ref StringBuilder ErrorMessage); 当我尝试按照这篇文章 ，当我运行这个例子（从下载的代码），它运行没有问题（所使用的DLL是在bin / debug文件夹）
我已经复制我的dll（以及它依赖的所有文件到我的bin文件夹中）。
我也试过这种方法，但得到了同样的错误：
[DllImportAttribute(MyOwnLibDllPath, EntryPoint="TMproIni")] [return: MarshalAs(UnmanagedType.I4)] public static extern int MyproIni(string DBname, string DBuser_pass, string WorkDirectory, ref StringBuilder ErrorMessage);
有什么build议么？
从我记得在Windows上的DLL的search顺序是：
- 当前目录
- 系统文件夹，
C:\windows\system32 or c:\windows\SysWOW64（对于64位盒上的32位进程）。 - 从
Path环境variables读取
另外我会检查DLL的依赖关系，Visual Studio提供的依赖关系助手可以在这里帮助你，也可以免费下载： http : //www.dependencywalker.com
您可以使用dumpbin工具来找出所需的DLL依赖关系：
dumpbin /DEPENDENTS my.dll
这将告诉你你的DLL需要加载哪些DLL。 特别注意MSVCR * .dll。 我已经看到您的错误代码时没有安装正确的Visual C ++可再发行组件。
您可以从Microsoft网站获得“Visual Studio 2013的Visual C ++可再发行组件包”。 它安装了c：\ windows \ system32 \ MSVCR120.dll
在文件名中，120 = 12.0 = Visual Studio 2013。
请注意，您的DLL的目标平台有正确的Visual Studio版本（10.0 = VS 10，11 = VS 2012，12.0 = VS 2013 …）右侧体系结构（x64或x86），同时还需要小心debugging构build。 DLL的debugging版本取决于MSVCR120d.dll，它是库的debugging版本，与Visual Studio一起安装，而不是由可再发行组件包安装。
尝试inputdll的完整path。 如果不起作用，请尝试将dll复制到system32文件夹中。
DLL必须位于bin文件夹中。
在Visual Studio中，我将dll添加到我的项目（不是在引用中，而是“添加现有文件”）。 然后将dll的“复制到输出目录”属性设置为“Copy if newer”。
确保您自己的dll的所有依赖项都存在于dll或System32附近。
有一件非常有趣的事情（并且具有技术相关性）可能会浪费你的时间，所以想到在这里分享它 –
我创build了一个控制台应用程序项目ConsoleApplication1和一个类库项目ClassLibrary1 。
所有使p / invoke的代码都存在于ClassLibrary1.dll 。 因此，在从Visual Studiodebugging应用程序之前，我只需将C ++非托pipe程序集（ myUnmanagedFunctions.dll ）复制到ClassLibrary1项目的\bin\debug\目录中，以便CLR可以在运行时加载它。
我不断收到
无法加载DLL
几个小时的错误。 后来我意识到，所有这些要加载的非托pipe程序集都需要复制到启动项目ConsoleApplication1的\bin\debug目录中，该程序通常是一个win窗体，控制台或web应用程序。
因此，请谨慎接受的答案中的Current Directory实际上是指您的应用程序进程开始的主要可执行文件的Current Directory 。 看起来像是一件显而易见的事情，但有时候可能不会如此。
经验教训 – 始终将未pipe理的dll放在与启动可执行文件相同的目录中，以确保可以find它。
打开融合日志logging，看到这个问题有很多关于如何做到这一点的build议。 debugging混合模式的应用程序加载问题可能是一个正确的皇家痛苦。 融合日志可以是一个很大的帮助。
确保将Build Platform Target设置为x86或x64，以便与您的DLL兼容 – 可以针对32位平台编译该DLL。
如果DLL和.NET项目在同一个解决scheme中，并且想要每次都编译和运行，则可以右键单击.NET项目的属性，生成事件，然后在Post-build事件中添加如下内容命令行：
copy $(SolutionDir)Debug\MyOwn.dll .
它基本上是一个DOS行，你可以根据你的DLL的build立位置来调整。
当我将应用程序部署到testingPC时，我遇到了同样的问题。 问题是发展个人电脑有msvcp110d.dll和msvcr110d.dll但不是testingPC。
我在InstalledSheild中添加了“Visual Studio C ++ 11.0 DebugCRT（x86）”合并模块并且工作。 希望这会对别人有帮助。
安装程序 ：32位Windows 7
上下文 ：由于上述问题，安装了无法通信的PCI-GPIB驱动程序。
简答 ：重新安装驱动程序。
长答 ：我还使用了Dependency Walker ，它确定了几个缺失的依赖模块。 马上，我认为它一定是一个拙劣的驱动程序安装。 我不想检查和恢复每个丢失的文件。
我无法在控制面板的“程序和function”下find卸载程序，这是安装不当的另一个指标。 我必须手动删除\ system32和registry项中的几个* .dll以允许重新安装驱动程序。
问题已修复。
意想不到的部分是，并不是所有的依赖模块都解决了。 尽pipe如此，感兴趣的* .dll现在可以被引用。
这是一个“kludge”， 但你至less可以用它来完善testing：在代码中尝试硬编码DLL的path
[DllImport(@"C:\\mycompany\\MyDLL.dll")]
话说回来; 在我的情况dumpbin /DEPENDENTS按照@ anthony-hayward的build议运行dumpbin /DEPENDENTS ，并将32位版本的DLL列表复制到我的工作目录，为我解决了这个问题。
该消息只是有点误导，因为它不是“我的”DLL无法加载 – 这是依赖
我认为你的非托pipe库需要一个清单。
这里是如何将它添加到你的二进制文件。 这是为什么。
总之，几个Redistributable库版本可以安装在你的盒子里，但是其中只有一个可以满足你的应用程序，并且它可能不是默认的，所以你需要告诉系统你的库需要的版本，这就是清单的原因。
