引入NETStandard.Library依赖项时出现System.*参考问题 [英] System.* reference troubles when introducing NETStandard.Library dependency

问题描述

在具有52个项目的大型解决方案(全部为net462)中，某些依赖项的最新版本现在仅针对NET标准构建.因此，它们依赖于NuGet包 NETStandard.Library ，该包反过来又拖入了其他许多4.3.x版本的 System.* 包，这些包通常在.NET Framework中本身.

因此，某些项目从packages文件夹中引用 System.* 库，而其他项目则从.NET Framework中引用 System.* 库.

这会导致众所周知的运行时问题，例如:

消息:System.IO.FileLoadException:无法加载文件或程序集"System.Net.Http，版本= 4.1.1.2，区域性=中性，PublicKeyToken = b03f5f7f11d50a3a"或其依赖项之一.找到的程序集的清单定义与程序集引用不匹配.(来自HRESULT的异常:0x80131040)

深入研究 NETStandard.Library 包的依赖项，我们可以看到这些包中也存在相同的问题:

• System.Collections.*
• System.ComponentModel.*
• System.Console
• System.Globalization.*
• System.IO.*
• System.Linq.*
• System.Net.*
• System.ObjectModel
• System.Reflection.*
• System.Resources.ResourceManager
• System.Runtime.*
• System.Text.*
• System.Threading.*
• System.Xml.*

通常可以通过在其他项目中安装相同的软件包来解决此问题，但是我们正在处理很多项目和许多软件包，我不想盲目地将所有这些依赖项添加到所有52个项目中

这使我想知道是否有人知道一种简单的方法可以从这种情况中恢复，并使所有项目(如果当前使用NET Framework内部的软件包)从NuGet软件包文件夹中引用正确的软件包/DLL.

可以在

5. 将软件包的相同版本(在您的情况下为4.3.0)安装到 ConsoleApp1 项目中.

6. 检查结果:

7. 重建解决方案.

完成.

---

此外，将软件包版本合并到解决方案中也是一种很好的做法.相反，您可能在构建期间发生版本冲突.或者，更糟糕的是，由于绑定重定向到依赖关系的另一个版本，导致运行时错误(如 MethodNotFound ).

---

针对 System.Net.Http 的问题的原因描述如下:损坏的System.Net.Http 4.1.1-4.3.0验尸 将来如何避免这种情况? 2.1

结果，我们确定了2个有问题的OOB程序包，它们不是平台本身的叶节点，并且具有平台依赖性，它们是System.Net.Http和System.IO.Compression.

这意味着.NET Framework中随附了相同的 System.Net.Http 库，并且是OOB(带外)nuget包.并且一些nuget软件包可以引用它的nuget版本.这就是我一开始就描述的问题.

因此，您不必修复对所有 System.* 库的引用.仅针对这两个: System.Net.Http 和 System.IO.Compression .

In a large solution with 52 projects (all net462), the latest version of some of our dependencies are now only built for NET standard. Therefore they depend on the NuGet package NETStandard.Library which in turn drags in a lot of other 4.3.x version of System.* packages which are normally in the .NET Framework itself.

As a result, some projects reference System.* libraries from the packages folder, while others reference System.* libraries from the .NET Framework.

This causes the well-known runtime issue, f.e.:

Message: System.IO.FileLoadException : Could not load file or assembly 'System.Net.Http, Version=4.1.1.2, 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)

Digging into the dependencies of the NETStandard.Library packages, we can see that the same issue also exists in these packages:

• System.Collections.*
• System.ComponentModel.*
• System.Console
• System.Globalization.*
• System.IO.*
• System.Linq.*
• System.Net.*
• System.ObjectModel
• System.Reflection.*
• System.Resources.ResourceManager
• System.Runtime.*
• System.Text.*
• System.Threading.*
• System.Xml.*

Normally this is fixed by installing the same package in the other projects, but we're dealing with a lot of projects and a lot of packages here and I don't want to blindly add all of those dependencies to all 52 projects.

This made me wonder whether anyone knows of an easy way to recover from this situation and to make all projects reference the correct package/DLL from the NuGet packages folder if they currently use the NET Framework internal one.

A simple VS-solution for net462 and net471 demonstrating the problem can be found here

解决方案

In the default project template System.Net.Http is added to the project as a reference, not as a nuget package.

In both of your solutions (4.6.1 and 4.7.1):

• Project ClassLibrary has a dependency on System.Net.Http as a nuget package.

• Project ConsoleApp1 has a dependency on System.Net.Http as a simple reference from .NET Framework

So, the issue is not related to Target Framework version.

To fix the issue add the same version of System.Net.Http as a nuget package to all projects (where it is used).

1. Right-click the solution in Solution Explorer and choose Manage NuGet Packages for Solution...

2. Switch to Installed tab

3. Find System.Net.Http in the list, select it.

4. Check current state:

5. Install the same version of the package (4.3.0 in your case) to ConsoleApp1 project.

6. Check the result:

7. Rebuild the solution.

Done.

---

Also, it's good practice to have package versions consolidated in your solution. Instead, you could have version conflicts during build time. Or, which is worse, runtime error like MethodNotFound because of binding redirect to another version of the dependency.

---

The reason for the problem with System.Net.Http is described here: Broken System.Net.Http 4.1.1-4.3.0 post-mortem in section How to prevent such situation in future? 2.1

As a result we identified 2 problematic OOB packages, which are not leaf-nodes in the platform itself, and have dependency from the platform on them - System.Net.Http and System.IO.Compression.

It means that the same System.Net.Http library is shipped within .NET Framework and as OOB (out-of-band) nuget package. And some nuget packages could reference nuget version of it. And here it comes the problem that I described at the very beginning.

So, you don't have to fix references to all System.* libraries. Only for these two: System.Net.Http and System.IO.Compression.

这篇关于引入NETStandard.Library依赖项时出现System.*参考问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！