windows 如何检查DLL依赖项？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/7378959/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to check for DLL dependency?
提问by orlp
Sometimes when I'm doing a little project I'm not careful enough and accidentally add a dependency for a DLL that I am not aware of. When I ship this program to a friend or other people, "it doesn't work" because "some DLL" is missing. This is of course because the program can find the DLL on my system, but not on theirs.
有时当我在做一个小项目时，我不够小心，不小心为一个我不知道的 DLL 添加了一个依赖项。当我将此程序发送给朋友或其他人时，“它不起作用”，因为缺少“某些 DLL”。这当然是因为程序可以在我的系统上找到 DLL，但不能在他们的系统上找到。
Is there a way to scan an executable for DLL dependencies or execute the program in a "clean" DLL-free environment for testing to prevent these oopssituations?
有没有办法扫描可执行文件的 DLL 依赖项或在“干净的”无 DLL 环境中执行程序以进行测试以防止这些oops情况？
采纳答案by Luchian Grigore
Try Dependency Walker(last update in 2006) or a modern rewrite of it called Dependencies.
尝试Dependency Walker（上次更新于 2006 年）或对其进行现代重写，称为Dependencies.
回答by JeffRSon
dumpbinfrom Visual Studio tools (VC\bin folder) can help here:
dumpbin来自 Visual Studio 工具（VC\bin 文件夹）可以在这里提供帮助：
dumpbin /dependents your_dll_file.dll
回答by troyane
I can recommend interesting solution for Linux fans. After I explored this solution, I've switched from DependencyWalker to this.
我可以为 Linux 爱好者推荐有趣的解决方案。在我探索了这个解决方案之后，我从 DependencyWalker 切换到了这个。
You can use your favorite lddover Windows-related exe, dll.
您可以ldd在与 Windows 相关的exe, dll.
To do this you need to install Cygwin(basic installation, without additional packages required) on your Windows and then just start Cygwin Terminal. Now you can run your favorite Linux commands, including:
为此，您需要在 Windows 上安装Cygwin（基本安装，无需其他软件包），然后启动Cygwin Terminal. 现在您可以运行您最喜欢的 Linux 命令，包括：
$ ldd your_dll_file.dll
UPD:You can use lddalso through git bash terminal on Windows. No need to install cygwin in case if you have git already installed.
UPD：您也ldd可以通过Windows 上的 git bash 终端使用。如果您已经安装了 git，则无需安装 cygwin。
回答by Iamsodarncool
Figure out the full file path to the assembly you're trying to work with
Press the start button, type "dev". Launch the program called "Developer Command Prompt for VS 2017"
In the window that opens, type
dumpbin /dependents [path], where[path]is the path you figured out in step 1press the enter key
找出您要使用的程序集的完整文件路径
按开始按钮，输入“dev”。启动名为“VS 2017 开发人员命令提示符”的程序
在打开的窗口中，输入您在步骤 1 中找到的路径
dumpbin /dependents [path]在哪里[path]按回车键
Bam, you've got your dependency information. The window should look like this:
Bam，你有你的依赖信息。窗口应如下所示：
Update for VS 2019:you need this package in your VS installation: 
VS 2019 更新：您的 VS 安装中需要此包：
回答by Artyom
- There is a program called "Depends"
- If you have cygwin installed, nothing simpler then ldd file.exe
- 有一个程序叫做“Depends”
- 如果你安装了 cygwin，没有比 ldd file.exe 更简单的了
回答by eran
The safest thing is have some clean virtual machine, on which you can test your program. On every version you'd like to test, restore the VM to its initial clean value. Then install your program using its setup, and see if it works.
最安全的是有一些干净的虚拟机，你可以在上面测试你的程序。在您要测试的每个版本上，将 VM 恢复到其初始清洁值。然后使用它的设置安装你的程序，看看它是否有效。
Dll problems have different faces. If you use Visual Studio and dynamically link to the CRT, you have to distribute the CRT DLLs. Update your VS, and you have to distribute another version of the CRT. Just checking dependencies is not enough, as you might miss those. Doing a full install on a clean machine is the only safe solution, IMO.
Dll 问题有不同的方面。如果您使用 Visual Studio 并动态链接到 CRT，则必须分发 CRT DLL。更新您的 VS，您必须分发另一个版本的 CRT。仅检查依赖项是不够的，因为您可能会错过这些。在干净的机器上进行完整安装是唯一安全的解决方案，IMO。
If you don't want to setup a full-blown test environment and have Windows 7, you can use XP-Mode as the initial clean machine, and XP-Moreto duplicate the VM.
如果您不想设置完整的测试环境并拥有 Windows 7，您可以使用 XP-Mode 作为初始干净机器，并使用XP-More来复制 VM。
回答by Shiv
On your development machine, you can execute the program and run Sysinternals Process Explorer. In the lower pane, it will show you the loaded DLLs and the current paths to them which is handy for a number of reasons. If you are executing off your deployment package, it would reveal which DLLs are referenced in the wrong path (i.e. weren't packaged correctly).
在您的开发机器上，您可以执行该程序并运行Sysinternals Process Explorer。在下方的窗格中，它将显示加载的 DLL 以及它们的当前路径，出于多种原因，这很方便。如果您在部署包之外执行，它会显示在错误路径中引用了哪些 DLL（即未正确打包）。
Currently, our company uses Visual Studio Installer projects to walk the dependency tree and output as loose files the program. In VS2013, this is now an extension: https://visualstudiogallery.msdn.microsoft.com/9abe329c-9bba-44a1-be59-0fbf6151054d. We then package these loose files in a more comprehensive installer but at least that setup project all the dot net dependencies and drops them into the one spot and warns you when things are missing.
目前，我们公司使用 Visual Studio 安装程序项目来遍历依赖树并将程序输出为松散文件。在 VS2013 中，这是一个扩展：https://visualstudiogallery.msdn.microsoft.com/9abe329c-9bba-44a1-be59-0fbf6151054d 。然后，我们将这些松散的文件打包到一个更全面的安装程序中，但至少该安装程序会将所有 dot net 依赖项放在一个位置，并在缺少内容时向您发出警告。
回答by HidekiAI
In the past (i.e. WinXP days), I used to depend/rely on DLL Dependency Walker (depends.exe) but there are times when I am still not able to determine the DLL issue(s). Ideally, we'd like to find out before runtime by inspections but if that does not resolve it (or taking too much time), you can try enabling the "loader snap" as described on http://blogs.msdn.com/b/junfeng/archive/2006/11/20/debugging-loadlibrary-failures.aspxand https://msdn.microsoft.com/en-us/library/windows/hardware/ff556886(v=vs.85).aspxand briefly mentioned LoadLibrary fails; GetLastError no help
在过去（即 WinXP 时代），我曾经依赖/依赖 DLL Dependency Walker (depends.exe)，但有时我仍然无法确定 DLL 问题。理想情况下，我们希望在运行前通过检查找出问题，但如果这不能解决它（或花费太多时间），您可以尝试启用http://blogs.msdn.com/上所述的“加载程序快照” b/junfeng/archive/2006/11/20/debugging-loadlibrary-failures.aspx和https://msdn.microsoft.com/en-us/library/windows/hardware/ff556886(v=vs.85).aspx并简要提到LoadLibrary 失败；GetLastError 没有帮助
WARNING: I've messed up my Windows in the past fooling around with gflag making it crawl to its knees, you have been forewarned.
警告：我过去曾用 gflag 鬼混弄乱了我的 Windows，让它爬到膝盖上，你已经被预先警告了。
Note: "Loader snap" is per-process so the UI enable won't stay checked (use cdb or glfags -i)
注意：“Loader snap”是针对每个进程的，因此 UI 启用不会保持选中状态（使用 cdb 或 glfags -i）
回答by Patrick from NDepend team
NDepend was already mentioned by Jesse (if you analyze .NET code) but lets explain exactly how it can help.
Jesse 已经提到了 NDepend（如果您分析 .NET 代码），但让我们解释一下它如何提供帮助。
Is there a program/script that can scan an executable for DLL dependencies or execute the program in a "clean" DLL-free environment for testing to prevent these oops situations?
是否有程序/脚本可以扫描 DLL 依赖项的可执行文件或在“干净”的无 DLL 环境中执行程序以进行测试以防止这些 oops 情况？
In the NDepend Project Properties panel, you can define what are application assemblies to analyze (in green) and NDepend will infer Third-Party assemblies used by application ones(in blue). A list of directories where to search application and third-party assemblies is provided.
在 NDepend 项目属性面板中，您可以定义要分析的应用程序集（绿色），NDepend 将推断应用程序使用的第三方程序集（蓝色）。提供了搜索应用程序和第三方程序集的目录列表。
If a third-party assembly is not found in these directories, it will be in error mode. For example if I remove the .NET Fx directory C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319I can see that .NET Fx third-party assemblies are not resolved:
如果在这些目录中找不到第三方程序集，它将处于错误模式。例如，如果我删除 .NET Fx 目录，C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319我可以看到 .NET Fx 第三方程序集未解析：
Disclaimer: I work for NDepend
免责声明：我为 NDepend 工作
回答by Jesse
If you have the source code, you can use ndepend.
如果您有源代码，则可以使用 ndepend。
It's pricey and does a lot more than analyzing dependencies so it might be overkill for what you are looking for.
它价格昂贵，而且所做的不仅仅是分析依赖关系，因此对于您正在寻找的内容来说可能有点过头了。
