企业官网建设流程全解析

Dependencies 命令行使用手册：如何定位缺失 DLL、导出导入/导出表并把 JSON 输出接入 CI

【免费下载链接】DependenciesA rewrite of the old legacy software "depends.exe" in C# for Windows devs to troubleshoot dll load dependencies issues.项目地址: https://gitcode.com/gh_mirrors/de/Dependencies

Dependencies 是一款用 C# 重写的 DLL 依赖分析工具，它的命令行版 Dependencies.exe 能递归导出 PE 文件的完整依赖链和函数级导入/导出表，并可用-json输出结构化结果，适合把"缺失 DLL 回归检查"放进 CI 流水线。

为什么排查 DLL 问题要用 Dependencies 而不是 depends.exe

面向 Windows 开发者排查"程序为什么起不来、DLL 到底从哪加载"的痛点。老版 depends.exe 早已停止演进，Dependencies 提供四个命令行友好特性：

• 递归依赖树，每个节点标注发现策略，解析失败一眼可见
• 函数级导入/导出表，序数导入与延迟加载均有标注
• -json结构化输出，结果可直接被脚本消费
• -cache二进制缓存，分析时不锁文件

获取 Dependencies.exe 的两种途径与首次运行

源码构建：先拉取代码，

git clone https://gitcode.com/gh_mirrors/de/Dependencies

然后用 Visual Studio 打开 Dependencies.sln，在配置栏手动选择Release和x64再编译——两者都不是默认值，不切换会构建失败或产出错误平台的产物。

下载发布包：到项目 Releases 页面下载压缩包解压，内含两个二进制：Dependencies.exe是命令行版，DependenciesGui.exe是 GUI 版，本文只讲前者。

⚠️ 两个易踩的坑：受 /clr 编译限制，运行 Dependencies 需已安装 Visual C++ Redistributable；二进制未签名，SmartScreen 可能弹警告，属正常现象。

所有功能的最简调用格式：

Dependencies.exe [OPTIONS] <FILE>

这条命令接收一个 PE 文件作为目标；不带参数或加-help会打印完整参数列表（参数定义见 Dependencies/Program.cs）。

导出完整依赖树的命令写法

最常见的场景是：程序起不来，报错"找不到指定的模块"，需要先确认依赖断在哪一层：

Dependencies.exe -chain MyApp.exe Dependencies.exe -chain -depth 2 MyApp.exe

前者递归展开全部层级，后者把递归限制在 2 层、适合控制输出量（默认不限深度）。输出每行形如├ 模块名 (策略) : 路径，括号里的策略是找到该 DLL 的搜索方式，常见有SxS、ApiSetSchema、WellKnownDlls、System32Folder、Environment，完整枚举定义在 DependenciesLib/FindPeModule.cs。标注NOT_FOUND的节点就是缺失的 DLL，路径为空。

GUI 版的树结构与-chain输出来自同一套解析引擎，只是做了可视化。若只想要"解析出了哪些模块"的扁平清单，可用-modules；注意该命令不支持-json（程序会直接提示），自动化脚本里请改用-chain。

查看函数级导入表与导出表的命令写法

依赖树完整但程序仍启动失败时，问题多半在函数级：入口点缺失、延迟加载的 DLL 运行时失败，这类情况用：

Dependencies.exe -imports MyApp.exe Dependencies.exe -exports kernel32.dll

-imports按模块分组列出导入函数，序数导入显示为Ordinal_xxx，延迟加载的条目带(Delay Import)标注——这类 DLL 只有真正被调用时才加载，是运行时故障的常见来源。-exports列出每个导出的名称、序数与虚拟地址，出现ForwardedName说明该导出是转发器，真正实现位于另一个模块。

对 .NET 文件还有两个专属开关：

Dependencies.exe -assemblyrefs MyApp.exe Dependencies.exe -modulerefs MyApp.exe

前者列出程序集引用并尝试在本地解析出版本号，后者列出模块引用；对纯原生文件两者都会得到空结果。同一文件还可以用-manifest转储内嵌 SxS 清单（XML）、用-sxsentries列出 SxS 依赖项，未找到的会标注???（解析逻辑见 DependenciesLib/SxsManifest.cs）。

查询系统级 KnownDlls 与 ApiSet 重定向的命令

"为什么加载的是 System32 里的同名 DLL 而不是我应用目录的"、"api-ms-win-core-*.dll到底指向哪个宿主"，这两类问题不需要目标文件：

Dependencies.exe -knowndll Dependencies.exe -apisets

-knowndll分 32 位与 64 位两段列出 KnownDlls 白名单，命中白名单的模块永远走系统版本，放在应用目录也没用。-apisets转储系统 ApiSet 重定向表（api set dll -> 宿主 dll），Windows 8.1 及以上报"找不到api-ms-win-*模块"，排查通常就从这张表开始。需要离线或跨机器对比时，可用-apisetsdll直接从apisetschema文件解析，仓库自带测试素材 test/apisetschema.v6.dll。

⚠️ 两条命令读的是当前机器状态，换一台机器运行，结果可能不同。

让 -json 输出接入 CI 的三种玩法

多数转储命令都能加-json，拿到缩进 JSON，结果就可以 diff、可以断言：

Dependencies.exe -json -chain MyApp.exe > deps.json

输出中每个节点带ModuleName、SearchStrategy、Filepath、Dependencies等字段。三种常见玩法：

1. 变更检测：每次构建导出快照，与基线 diff，依赖集悄悄变化就能发现；
2. 缺失 DLL 断言：递归查找SearchStrategy为NOT_FOUND的节点，命中即让流水线失败；
3. 报告归档：把deps.json存为构建产物，事后排查有据可查。

前两种在 PowerShell 里可以直接做：

$d = ConvertFrom-Json (Get-Content deps.json -Raw)

这一行把 deps.json 反序列化成 PowerShell 对象，之后只需递归找NOT_FOUND节点判定成败，无需额外依赖。仓库的回归脚本 test/manifest-regress/Test-ManifestRegress.ps1 展示了如何对 Dependencies 的输出做断言包装。

📌-modules不支持 JSON 输出，自动化场景请改用-chain或-imports。

Dependencies 命令行参数速查

谁应该把 Dependencies 放进工具箱

一句话总结：Dependencies 命令行把 depends.exe 式的排查能力做成了可脚本化的形态——-chain看树、-imports与-exports看函数、-json让结果可 diff 可断言。如果你是常排查 DLL 加载问题的 Windows C/C++/C# 开发者，或是想把"缺失依赖"检查纳入流水线的 CI 工程师，值得把它与 dumpbin、procmon 一起放进工具箱。

【免费下载链接】DependenciesA rewrite of the old legacy software "depends.exe" in C# for Windows devs to troubleshoot dll load dependencies issues.项目地址: https://gitcode.com/gh_mirrors/de/Dependencies