Nuget DLL Hell：无法加载文件或程序集System.Runtime

Question

今天将 Application Insights 升级到最新版本后，由于我们的站点不再报告调用堆栈，我们的 .NET Framework 4.6.1 ASP.NET 站点现在在初始化时崩溃，原因如下：

System.IO.FileLoadException: 'Could not load file or assembly 'System.Runtime, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'

我过去在另一份工作中也曾遇到过类似的问题。关键区别在于该问题是由引入 .NET Core 或 Standard 的 Nuget 包引起的。因此，多个同名的 .NET DLL 被复制到 bin 文件夹（在这种情况下为 System.Net.Http）。在这种情况下，就像不再更新 Nuget 包一样“简单”......

尽管我认为这里的情况略有不同，但“不升级”不再是一个选择。Application Insights 不再报告调用堆栈有点违背了整个事情的目的！

由于它是 System.Runtime，而不是 Nuget 包，因此配置文件中没有用于 nuke 的依赖版本标记；尽管这样也行得通，但无论如何，这似乎只是一个临时解决方案。

我推测现在项目中的某个地方可能隐藏着 .NET Core 的 .NET 标准，但我没有看到 NetStandard 参考，而且我不知道如何判断 Core 是否被以某种方式拖入。我还没有愉快地（？）使用标准版或核心版，还没有立即了解更多信息。我会继续谷歌搜索...

我认为这是因为我们有一个 .NET 3.5 DLL（除了普通的 .NET Framework 3.5 的 System、System.Runtime.Serialization 和 System.Xml 之外，Nuget 或 DLL 引用为零），被 ASP.NET 项目引用，尽管这以前从未出现过问题。

我完全被难住了，并停止了当天的所有开发。我一直在升级和降级各种软件包，查看它们的先决条件，但我没有找到任何提示。

Answer 1

两个不同的 Nuget 想要引入不同版本的 System.Runtime.dll。这在使用使用 .NET Standard 的 Nuget 的 .NET 项目中极为常见。这是我第二次遇到源自 System.Net.Http 的问题，因为几乎每个人都使用它。Program Files\Reference Assemblies由于 System.Runtime 是一个 .NET Framework DLL，因此无论您在 Visual Studio 或 CSProj 中执行什么操作，&nbsp;Visual Studio 都会始终从该文件夹中获取它。就我而言，无论出于何种原因，复制到 bin 文件夹的版本是所需 DLL 的仅反射版本，这意味着我不能简单地使用标签来强制它使用<dependantAssembly>bin 文件夹中的版本。我必须首先将完整版本的 System.Runtime.dll 放入 bin 文件夹中。除了更新到 .NET Core 之外，我唯一的想法（并得到另一位 Stack Overflow 用户的证实）是在构建后手动复制它。这很糟糕，但它可以与您拥有的任何冲突的 DLL 一起使用：由于 Nuget 包的原因，您的项目引用中可能会存在冲突的 DLL。我的问题更困难，因为虽然 System.Runtime 是我使用的另一个 Nuget 的先决条件，但我想因为它是 .NET Framework 的一部分，所以它没有作为 Nuget 包或引用添加。如果没有，就自己去拉Nuget包。在包文件夹中查找 DLL 的路径。例如，我的是$(SolutionDir)packages\System.Runtime.4.3.1\lib\net462\System.Runtime.dll.&nbsp;您将需要$(SolutionDir)像我一样将解决方案目录与宏交换。在项目的解决方案属性中编辑构建后事件命令行：copy "$(SolutionDir)packages\System.Runtime.4.3.1\lib\net462\System.Runtime.dll" "$(TargetDir)System.Runtime.dll"在可以看到其版本号和公钥令牌的工具中打开 DLL，例如 ILSpy。就我而言，DLL 的版本为 4.1.1.1，公钥标记为 b03f5f7f11d50a3a。请注意，在文件资源管理器中查看 DLL 的属性不会显示正确的版本号。在文本编辑器中打开 app.config/web.config。如果标签中还没有<dependentAssembly>DLL 的标签configuration\runtime\assemblyBinding，请添加它。它应该看起来像这样：<dependentAssembly> &nbsp; &nbsp;<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/> &nbsp; &nbsp;<bindingRedirect oldVersion="0.0.0.0-9.9.9.9" newVersion="4.1.1.1"/> </dependentAssembly>（续）将该名称替换为不带 .DLL 扩展名的 DLL 文件名。将公钥标记替换为您在 ILSpy 中发现的值。将 oldVersion 设置为较宽的范围。将 newVersion 设置为您在 ILSpy 中找到的版本。每当您在 Nuget 包管理器中触摸该 nuget 包时，它可能会更改您的<dependentAssembly>标签！因此，在你的项目上留下一个文本文件、一张便利贴、一个霓虹灯标志，说明如果你弄乱了那个 Nuget 包，你可能需要编辑构建后和 app.config/web.config。哭。如果您像我一样被困在 .NET Framework 上，您可能最终不得不对许多 DLL 进行这种修改，因为 .NET Standard/Core 变得更加普遍，因此更多的 DLL 最终与它们的 .NET Framework 对应项具有相同的名称。我们发现将此解决方案部署到 Azure 上不起作用。否则，唯一的其他解决方案是完全避免它：一次仅升级一个 Nuget 包，并在每次之后进行彻底测试。Nuget 可以像俄罗斯轮盘赌;-)。尽管上述方法对我们有用，但我们最终还是回滚并缓慢而痛苦地升级，直到找到罪魁祸首。如果您知道更好的方法，我很想听听。