C# 如何在VS 2017中创建依赖性最小的.NET标准NuGet包？

我目前正在使用Visual Studio 2017迁移一个库项目以支持.NET标准1.1

我希望将该项目作为一个单独的NuGet包发布，可以同时针对.NETFramework 4.5+和.NETCore、UWP等

但是，当我尝试在.NET Framework项目中安装生成的包时，会生成一个庞大的包依赖项列表，其中包含在.NET标准中定义的所有包（请参见下文）：

我知道这些都是作为.NET标准1.1规范的一部分定义的程序集。然而，我的特定项目实际上只需要它们中的一小部分，并且对于在项目中安装包的任何人来说，这个依赖项列表都会非常混乱

我试图遵循一个问题的答案，其中的建议是更改项目规范，以仅引用项目所需的确切依赖项

然而，答案是在旧的project.json格式的背景下得出的，该格式在VS 2017中已被新的.csproj格式取代。我试图通过删除

指令来删除对.NET标准1.1元包的依赖关系，但我只设法破坏了构建，无法找到任何方法专门添加所需的依赖关系

---

将库迁移到.NET标准以实现最大的平台兼容性的承诺非常吸引人，但建议采用什么方法来构造依赖关系，以使针对“classic”.NET Framework的项目不会发现其项目受到“污染”通过所有这些依赖关系？

将

更改为

并添加

；net45

将其连接到它。您仍然会得到一个NuGet软件包输出，但现在如果您的目标是.NET core应用程序（该应用程序已经具有依赖项），它只会引入额外的依赖项。

如果查看net45的这些软件包引用，您会发现没有实际的DLL可加载。包在那里，这样运行时（比如coreclr）就可以获得它们，coreclr将BCL的所有部分作为dll加载。然而，在net45中，您实际上无法在这些包中找到任何dll

简而言之，在.net 4.x中，.net仍将使用GAC来加载这些程序集。

首先，我想指出的是，这主要是一个设计时问题，不会影响生成的应用程序和库的可移植性：

过去，我们建议开发人员不要引用NuGet包中的元包（

NETStandard.Library

），而是引用单个包，如

System.Runtime

和

System.Collections

）。其基本原理是，我们认为元包是一堆包的简写，这些包是.NET平台的实际原子构建块。假设是：我们最终可能会创建另一个.NET平台，该平台只支持其中一些原子块，但不支持所有原子块。还有人担心我们的工具如何处理大型包图

接下来，我们将简化此过程：

.NET标准是一个原子构建块。换句话说，新平台不允许对.NET标准进行子集划分——它们必须实现所有这些

我们不再使用软件包来描述我们的平台，包括.NET标准

这意味着，您将不必再为.NET标准引用任何NuGet包。您使用lib文件夹表达了您的依赖关系，这正是它在所有其他.NET平台，特别是.NET Framework上的工作方式

但是，现在我们的工具仍然会在对

NETStandard.Library

的引用中烧掉。这也没有什么坏处，向前推进只会变得多余

然而，我完全承认，这一结果很难令人满意

使用.NET标准1.x和

packages.config

，很遗憾，您别无选择，只能生成带有自定义依赖组的手写.nuspec。然而，这需要了解哪些包装是必需的，而且往往是易碎的。如果消费者使用

，那就不会那么令人头痛了，因为它将直接引用和传递引用分开，因此这些引用在你的脸上并不多见

---

使用.NET标准2.0，问题将完全消失。

您需要在NuGet定义文件中为每个平台定义依赖项。阅读开放源代码项目，如ANTLR 4 runtime。@LexLi是的，我知道这个解决方案，但.NET标准的全部要点是，您可以将单个DLL分发到所有平台，而不必经历PCL的噩梦。您显然低估了实现它所需的努力。我的观点是，无论有多少DLL，所有平台的.NET本机最终都会解决所有这些问题，但它不会来得足够快。@LexLi我认为他们已经实现了这一点，因为同一个DLL确实可以在支持.NET标准的所有.NET平台上运行。目前的问题只涉及依赖性解决，这似乎在他们提出的标准化框架内是非常可以解决的。无论如何，现在很明显，我误解了当前版本的.NET标准在标准化部署包方面的含义。短语“所有.NET平台”应该缩小为“所有新的.NET平台”。支持旧版本，如.NET Framework 4.5/4.5.1，尽管已列出，但并不那么容易。标准这么晚才出台，所以耍花招是不可避免的。它是未来的标准，但不是过去的标准（尽管在包含旧的比特时，比如Windows Phone，它假装是）