为什么我的 .NET Standard NuGet 包会触发如此多的依赖项？

我一直在闲逛.NET 标准项目 https://github.com/tdwright/contabs和 NuGet。我有一个工作项目并且有已将其上传到 NuGet.org https://www.nuget.org/packages/ConTabs.tdwright/0.1.0。我的项目面向 .NET Standard 1.3，其中应该支持 https://learn.microsoft.com/en-us/dotnet/standard/net-standard.NET Framework 4.6 和 .NET Core 1.0。

但是，当我尝试将我的项目（通过 NuGet）添加到新的 .NET Framework 4.6 项目时，依赖关系解析为47包！它们都是系统库，并且似乎是 Microsoft.NETCore.Platforms 或 NETStandard.Library 1.6.1 的依赖项。 （完整 PM 输出的要点。 https://gist.github.com/tdwright/0b3568a9da2e318fe6e3c2efc40fcff4)

我的项目仅导入（using）一些库，其中没有一个是我手动添加的；即它们都是“附带”.NET Standard 的库。这些库是：

1. System
2. 系统.文本
3. 系统.反射
4. 系统Linq
5. 系统.集合.通用;

问题是，我决定让我的项目以 .NET Standard 为目标，因为我希望它能够跨 .NET Framework 和 .NET Core 应用程序无缝工作。我认为标准的全部要点是设置最低级别的兼容性。通过扩展，我想我假设（可能是错误的）像 System.Console 这样的库将在 Core 或 Framework 中自动可用。

当我将我的标准项目作为同一解决方案中的框架和核心项目的依赖项进行测试时，我没有注意到类似的情况，因此我怀疑这可能是 NuGet 的事情。

这里究竟发生了什么？如何在没有大量依赖项的情况下使我的 .NET Standard 库在 NuGet 上可用？

我指定 NuGet 包的方式有问题吗？或者我从根本上误解了什么？

你没有做错任何事，这是预料之中的事情。如果您只想将自己的 DLL 添加到新的 .NET Framework 项目中，那么您的库必须以 .NET Standard 2.0 为目标，等待本机支持 API 和程序集版本的 .NET Framework 版本 - 这将是更新为 4.7.2（虽然 .NET Framework 4.7.1 支持所有 API，但某些程序集的版本控制方式存在错误，因此工具 (VS 2017 15.5+) 将添加其他程序集来修复该问题）。

您所看到的是 .NET Standard 的构建方式以及对受支持框架的支持的实现方式的副作用。根据您的目标 .NET Standard 版本以及用于引用库包的工具，这也有所不同。

在 .NET Standard NETStandard.Library元包又引用了额外的（System.*) 包。这些包包含构成“.NET 标准合约”的参考程序集 - 一组 API 和程序集名称 + 版本。

当应用程序引用为 .NET Standard 1.0-1.6 创建的 NuGet 包时，这些单独的包不会引入引用程序集，而是引入应用程序目标框架的实现程序集。

对于 .NET Core，这些与已经属于运行时一部分的程序集相匹配，因此 DLL 文件不会最终出现在构建的应用程序旁边。然而，当针对 .NET Core 1.1 发布一组新的包时，情况发生了变化（NETStandard.Library版本 1.6.1)。这导致为 .NET Core 1.0 构建的应用程序最终获得了本应包含在 .NET Core 1.1 中的更新的实现程序集（幸运的是，1.1 随后成为“长期支持”版本，因为这引发了关于哪些程序集的讨论）是 LTS 承诺的一部分）。

在 .NET Framework 上，这些库（有一些例外，例如System.Net.Http）不做太多事情 - 他们只是转发到系统程序集。例如，“合同”定义了System.Object被定义在一个System.Runtime.dll集会。所以System.Runtime.dll您最终在 .NET Framework 应用程序中得到的文件包含System.Runtime.dll包含转发到 .NET Framework 的类型mscorlib.dll。 .NET Core 已经包含了不同的System.Runtime.dll这对该平台做了一些不同的事情。此机制允许单个 DLL 文件在两个平台上工作，因为这些类型转发和附加实现确保在两个实现上工作的相同“契约”（类型 + 程序集 + 程序集版本）。

.NET Standard 2.0 旨在减少必要的包和 DLL 的数量，并消除对NETStandard.Library每当发布新的 .NET Core 版本时。

因此，对于 .NET Standard 2.0 和 .NET Core 2.0，NETStandard.Librarypackage 仅将用于编译代码的参考程序集引入项目，但生成的 NuGet 包不再依赖于此包。因此，当您创建面向 .NET Standard 2.0 的库并发布它时，它将没有 NuGet 依赖项（除非您添加其他依赖项）。

使用 .NET Standard 库时引入的“支持库”的逻辑已移至构建期间使用的工具中。因此，当一个库包含对netstandard.dll添加到 .NET Framework 项目后，该工具将根据所使用的 .NET Framework 版本添加必要的支持 DLL。这是针对 .NET Standard 2.0 以及 .NET Standard 1.5+ 完成的，因为 .NET Framework 4.6.1 通过这些类型的 DLL 文件追溯地与 .NET Standard 2.0（之前为 1.4）兼容。相同的工具还确保即使 NuGet 包以某种方式引入到此类应用程序项目中，通过 NuGet 引入的任何 .NET Standard 实现库也会从构建中删除。因此，如果您引用在 .NET Core 1.0 发布时构建的 .NET Standard 1.0 NuGet 包，则其所有 NuGet 依赖项都会被删除，您将获得构建工具附带的支持库。

这个想法是 .NET Framework 4.7.1 将包含所有必要的程序集“收件箱”，以便netstandard.dll, System.Runtime.dll等是 .NET Framework 的一部分，任何 .NET Standard 1.0-2.0 DLL 文件都会“正常工作”，问题是这些“收件箱”DLL 文件对于某些程序集来说版本号太低，因此库将无法加载 -通过再次更改工具以包含具有更高版本号的 DLL 文件作为支持库，这些文件又转发到“收件箱”.NET Framework 程序集，解决了此问题。计划在 .NET Framework 4.7.2 中修复此问题。