VS C#中的依赖地狱，找不到依赖关系答案

【问题标题】：Dependency hell in VS C#, cannot find dependenciesVS C#中的依赖地狱，找不到依赖关系
【发布时间】：2019-09-11 07:24:24
【问题描述】：

我创建了一个图表 C# 库（我们称之为chartlibrary），它本身依赖于多个第三方 dll 文件。

在另一个可执行项目（我们称之为chartuser）中，我引用了chartlibrary 项目（这两个项目位于Visual Studio 中的同一个解决方案中）。

编译后可以看到chartlibrary引用的所有第三方dll文件也都包含在chartuser的bin/Debug文件夹下。但是，我得到一个运行时错误，它基本上表明chartlibrary 中的某些引用无法解析。然后我试图通过

获得更好的主意

AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;

和

private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
    {
        var assemblyFileName = args.Name.Substring(0, args.Name.IndexOf(",")) + ".dll";
        var assemblyPathFileName = _currentPluginPath + @"\" + assemblyFileName;

        if (File.Exists(assemblyPathFileName))
        {
            return Assembly.Load(File.ReadAllBytes(assemblyPathFileName));
        }

        return null;
    }

问题是RequestingAssembly 为空，Name 非常神秘。

即使所有 dll 都在可执行项目的 bin/Debug 文件夹中，也无法找到引用 dll 并且无法解析程序集，我做错了什么？

【问题讨论】：

如果所有依赖项都在同一个文件夹中，则应该没有理由处理 AssemblyResolve 事件。您能否包括您收到的确切错误消息？有时，“...或其依赖项之一”表示第 3 方库本身具有附加依赖项。也许您可以尝试创建一个使用这些 3rd 方库的单一测试解决方案并查看它是否运行。

标签： c# visual-studio dependencies .net-assembly

【解决方案1】：

修复：针对与其混淆引擎相关的第三方库的修复解决了该问题。

.NET 依赖项：也许略过这个旧答案：How do I determine the dependencies of a .NET application? - 并浏览任何清单文件？

调试：The Microsoft Assembly Binding Log Viewer 可以显示运行时发生的情况。通过 Developer Command Prompt for Visual Studio 启动它（只需搜索“开发人员命令”，输入 "FUSLOGVW.exe" 并按 Enter）。也可以略读一下：How the Runtime Locates Assemblies。

我不太熟悉它们的用途，但还有一些更进一步的工具（大多数除了依赖之外还有更多用途）：

ILSpy - 我相信它是开源的。
AsmSpy - 从未尝试过。
NDepend - 商业广告。

应用程序启动清单：

运行时：如果问题发生在另一台计算机上，清单上最明显的运行时：.Net、.Net Core、Java 、Silverlight、Direct X、VC++ Runtime、MS-XML (legacy)、Crystal Reports、Microsoft Report Viewer、SQL Server / Database Runtimes 等...加上任何涉及 COM 注册的内容以及您所指的任何第三方框架组件（COM、COM 互操作、GAC、程序集等...）。

其他链接：

Which winform project files should be packed up into the installer

【讨论】：

谢谢，虽然我知道需要哪个依赖项。问题是 dll 文件位于 bin/Debug 文件夹中，因此依赖项已正确复制到输出文件夹中。但是，不知何故，在依赖解析期间，似乎并未在实际输出文件夹中搜索这些 dll。
.NET 不是我的专长，所以如果这无关紧要，我们深表歉意：您在 GAC 中是否有任何东西 - （可能会干扰）？尝试过干净的系统？位数问题（x64、x86）？您是否对实际的源文件进行了比较，以查看它是否安全地放入了 Debug 文件夹？任何publisher policy files（对于assembly override）？也许可以区分配置文件？
硬编码参考？不确定这是否可能 - 没有实践经验。我将提供指向我的minimally psychotic list of things to check for unexpected stuff in your release files 的链接。
谢谢，让我细细琢磨一下你的帖子和cmet，我也在接触第三方依赖的开发者。
好的，谢谢！很高兴将其记录在案，以便看到相同问题的人可以找到它。对供应商也应该有好处吗？听起来他们很快就回来了。希望你们都对此进行排序。正如我的老同事常说的那样（在下一个问题中添加：-)）。