.NET 开发者福音Dependencies 如何用 Mono.Cecil 解析 CLR 程序集引用混合依赖一图看懂【免费下载链接】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/DependenciesDependencies 是一款用 C# 重写的开源依赖分析工具它借助 Mono.Cecil 解析 CLR 程序集引用让 .NET 开发者的原生依赖与托管依赖在同一个依赖树中一目了然。过去排查dll 加载失败native 依赖和 .NET 程序集引用往往要各查各的Dependencies 把两者合并成一张依赖图C# 与原生混合依赖一次看懂。先认识 DependenciesDependency Walker 的现代继任者老 Windows 开发者应该都用过随 Windows SDK 分发的 depends.exeDependency Walker可惜它自 2006 年起停止维护对 Win8.1 的 ApiSet、现代 .NET 程序几乎无能为力。Dependencies 正是用 C# 重新实现的现代版依赖漫游者面向 Windows 开发者的 dll 加载排错场景解析 PE 导入表、导出表并模拟 NT Loader 的 DLL 搜索路径支持 SxS 清单与 ApiSet 重定向用 Mono.Cecil 枚举 CLR 程序集引用把 .NET 依赖也画进依赖树 提供 GUI 与 CLI 双形态结果可导出为 JSON项目结构上Dependencies.sln 下主要有四个工程GUI 界面DependenciesGui、命令行工具Dependencies、核心解析库DependenciesLib以及封装 PE 底层能力的ClrPhlib。为什么 .NET 依赖必须另辟蹊径一个 C# 可执行文件的依赖分两层层级例子记录位置原生层user32.dll、mscoree.dllPE 导入表托管层System.Data.dll、自研 DLL.NET 元数据中的程序集引用P/Invokekernel32.dll通过 DllImport.NET 元数据中的模块引用普通 PE 工具只能看到第一层。Dependencies 的诀窍是一个简单可靠的判断只要 PE 导入表里出现了mscoree.dll就认为这是一个 C# 程序集见 DependencyWindow.xaml.cs 的注释。确认之后就交给 Mono.Cecil 登场。Mono.Cecil 解析 CLR 程序集引用的完整流程Mono.Cecil 是项目通过 NuGet 引入的 0.11.4 版本见 DependenciesGui/packages.config。核心逻辑在 DependencyWindow.xaml.cs 的ProcessClrImports方法中流程可以概括为四步触发判断检查当前解析的模块是否为mscoree.dll是才继续走 CLR 解析分支读取元数据AssemblyDefinition.ReadAssembly把 exe/dll 按 .NET 程序集打开遍历其中每个模块的AssemblyReferences程序集引用按路径解析用DefaultAssemblyResolver搜索目录加入了应用根目录把程序集引用解析到磁盘上的真实文件再走一遍 Dependencies 自己的模块搜索逻辑顺藤摸瓜找 P/Invoke遍历ModuleReferences把托管程序集里DllImport的原生 DLL 也一并纳入同样去磁盘上定位找不到文件的引用不会报错中断而是被标记为未找到继续分析。每个 CLR 来源的节点都会打上ModuleFlag.ClrReference标志定义在 ModuleInfo.cs并在搜索结果中标记为ClrAssembly策略见 FindPeModule.cs——这就是依赖树里 .NET 节点带引用小图标的来源图标切换逻辑在 Shell32IconExtractor.cs。⚠️ 一个已知边界对 .NET Core / .NET 5 的可执行文件Mono.Cecil 解析会抛出BadImageFormatException此时 Dependencies 会弹窗提示CLR imports will be not shownDependencyWindow.xaml.cs原生依赖分析不受影响。混合依赖树一图看懂的一图长什么样分析完成后左侧依赖树把三层来源混排在一起原生导入按 PE 导入表解析显示搜索路径System32、环境变量、SxS 等CLR 程序集引用带 Reference 叠加图标点击可看它在磁盘上的实际位置P/Invoke 原生 DLL同样走 CLR 解析分支发现与程序集并列展示树节点状态一目了然缺失模块显示红色无效图标延迟加载显示沙漏图标Status栏还会用英文短句直接说明原因例如xxx module could not be found on diskModuleInfo.cs。配合 Options → Properties 里的Tree build behaviour只分析直接导入 / 递归全量分析可以在速度和内存占用之间自行权衡。命令行也能查assemblyrefs 与 modulerefs不想开 GUI项目自带 CLI 工具Dependencies/Program.cs两个参数正好对应 Mono.Cecil 的两类引用-assemblyrefs 文件.dll列出 CLR 程序集引用并尝试解析到磁盘路径-modulerefs 文件.dll列出 P/Invoke 的原生模块引用-chain 文件.exe输出完整依赖链含 CLR 分支加-json可得 JSON 结果方便接入 CI 脚本 CLI 中的实现同样基于AssemblyDefinition.ReadAssembly参考 Program.cs 的PEModuleReferences与PEAssemblyReferences两个类。小结适合哪些人用✅ 遇到程序启动就闪退、报缺少某某 dll的 Windows 桌面应用开发者✅ 需要排查 C# 应用里托管 原生混合依赖的 .NET 开发者✅ 想替代老旧 depends.exe、做依赖回归检查的构建/发布工程师记住这条主线就够了看到 mscoree.dll → Mono.Cecil 读元数据 → 程序集引用和 P/Invoke 各归其位 → 全部汇进同一棵依赖树。从猜哪个 dll 丢了到一树看清这就是 Dependencies 给 .NET 开发者带来的福音。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考