根据metapackage，netstandard库的应用含义是什么？

假设我有一个类库，我想要的目标是netstandard1.3，但也使用BigInteger 。 这是一个简单的例子 – 唯一的源文件是Adder.cs ：

 using System; using System.Numerics; namespace Calculator { public class Adder { public static BigInteger Add(int x, int y) => new BigInteger(x) + new BigInteger(y); } } 

回到project.json的世界中，我将在frameworks部分中定位netstandard1.3 ，并明确依赖于System.Runtime.Numerics ，例如版本4.0.1。 我创build的Nuget包将只列出这个依赖关系。

在基于csproj的dotnet工具（我正在使用命令行工具的v1.0.1）这个勇敢的新世界中，当定位netstandard1.3时，有一个隐式的元数据包引用到NETStandard.Library 1.6.1 。 这意味着我的项目文件非常小，因为它不需要显式的依赖关系：

 <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netstandard1.3</TargetFramework> </PropertyGroup> </Project> 

…但生成的nuget包依赖于NETStandard.Library ，这表明为了使用我的小型图书馆，你需要一切 。

事实certificate，我可以使用DisableImplicitFrameworkReferences禁用该function，然后再次手动添加依赖项：

 <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netstandard1.3</TargetFramework> <DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences> </PropertyGroup> <ItemGroup> <PackageReference Include="System.Runtime.Numerics" Version="4.0.1" /> </ItemGroup> </Project> 

现在我的NuGet软件包确切地说它依赖于什么。 直觉上，这感觉就像一个“精简”的包。

那么，我的图书馆的消费者有什么区别呢？ 如果有人试图在UWP应用程序中使用它，第二个“修剪”forms的依赖关系是否意味着由此产生的应用程序会变小？

通过不清楚地loggingDisableImplicitFrameworkReferences （就我所见;我在一个问题中阅读了它），并通过在创build项目时将隐式依赖项设置为默认值，Microsoft 鼓励用户只依赖于元数据包 – 但是我怎么能当我生成一个类库包时，确定它没有缺点？

Answer 1

过去，我们给开发者build议不要引用NuGet包中的元包（ NETStandard.Library ），而是引用单个包，比如System.Runtime和System.Collections 。 理由是我们认为元软件包是作为.NET平台的实际primefaces构build块的一堆软件包的缩写。 假设是：我们可能最终创build另一个.NET平台，只支持这些primefaces块中的一部分，但不是全部。 因此，您引用的软件包越less，便携性就越高。 还有人担心我们的工具如何处理大型包图。

outlook未来，我们将简化这一点：

1. .NET标准是一个primefaces构build块 。 换句话说，新的平台不允许子集.NET标准 – 他们必须实现所有的。

2. 我们正在使用包来描述我们的平台 ，包括.NET标准。

这意味着，您不必再引用任何适用于.NET Standard的NuGet包。 你用lib文件夹expression了你的依赖，这正是它在所有其他.NET平台上的工作方式，特别是.NET Framework。

但是，现在我们的工具仍然会在对NETStandard.Library的引用中被NETStandard.Library 。 那也没有什么坏处，只会变得多余的前进。

我将更新.NET标准库中的常见问题以包含此问题。

更新 ：这个问题现在是FAQ的一部分 。

Answer 2

该团队曾经推荐搞清楚最薄的套装是什么。 他们不再这样做了，build议人们只需引入NETStandard.Library（对于SDK风格的项目，这将自动完成）。

我从来没有得到一个完全直截了当的答案，为什么这样做，所以让我做一些教育猜测。

主要原因可能是它允许他们隐藏在相关库的版本中的差异，否则当您更改目标框架时，您将需要跟踪自己的版本。 这也是一个更加用户友好的系统与基于SDK的项目文件，因为你坦白地不需要任何引用，以获得一个体面的块平台（就像你以前在Desktop-land的默认引用，特别是mscorlib ）。

通过推动将netstandard库或netcoreapp应用程序的元定义推入到适当的NuGet包中，他们不必像Visual Studio（或dotnet new ）那样对这些东西进行定义，看到他们。

在发布过程中可以使用静态分析来限制交付的DLL，这是他们在为UWP进行本地编译时所做的事情（尽pipe有一些注意事项）。 他们今天没有这样做的.NET核心，但我认为这是他们已经考虑的优化（以及支持本地代码）。

如果你愿意的话，没有什么可以阻止你的select。 我相信你会发现，你几乎是唯一一个这样做，这也失败了目的（因为它会被认为是每个人都引入NETStandard.Library或Microsoft.NETCore.App ）。

Answer 3

您不应该需要禁用隐式引用。 该库将能够运行的所有平台将已经有NETStandard.Library依赖项需要的程序集。

.NET标准库是一个规范，是您编译的一组参考程序集，它提供了一组确保存在于一组已知的平台和版本的平台上的API，例如.NET Core或.NET Framework 。 这不是这些程序集的实现，只是足够的API形状来让编译器成功地build立你的代码。

这些API的实现由目标平台提供，如.NET Core，Mono或.NET Framework。 他们随平台一起发货，因为他们是平台的重要组成部分。 所以没有必要指定一个更小的依赖关系集合 – 一切已经存在，你不会改变它。

NETStandard.Library包提供了这些引用程序集。 一个混乱的地方是版本号 – 包是版本1.6.1，但这并不意味着“.NET标准1.6”。 这只是包的版本。

您所定位的.NET标准版本来自您在项目中指定的目标框架。

如果你正在创build一个库，并希望它运行在.NET标准1.3上，你可以参考当前版本为1.6.1的NETStandard.Library包。 但更重要的是，你的项目文件将目标netstandard1.3 。

NETStandard.Library包将根据您的目标框架名字对象给你一组不同的引用程序集（为了简洁起见，我想简化一下，但是想一下lib\netstandard1.0 ， lib\netstandard1.1和依赖关系组 ）。 所以如果你的项目的目标是netstandard1.3 ，你会得到1.3的引用程序集。 如果你的目标是netstandard1.6 ，你会得到1.6的引用程序集。

如果您正在创build应用程序，则无法定位.NET标准。 这是没有意义的 – 你不能运行一个规范。 而是针对具体平台，如net452或netcoreapp1.1 。 NuGet知道这些平台和netstandard目标框架标记之间的映射，所以知道哪个lib\netstandardX.X文件夹与您的目标平台兼容。 它也知道NETStandard.Library的依赖关系是由目标平台满足的，所以不会NETStandard.Library到任何其他的程序集。

同样，当创build独立的.NET Core应用程序时，.NET Standard实现程序集将与您的应用程序一起复制。 对NETStandard.Library的引用不会引入任何其他新的应用程序。

请注意， dotnet publish将创build一个独立的应用程序 ，但它不会不修剪，并将发布所有程序集。 这将通过工具自动处理 ，所以再次，修剪库中的依赖关系在这里将无济于事。

我可以想象的唯一的地方，它可能有助于删除NETStandard.Library引用，如果你的目标是一个不支持.NET标准的平台，你可以从.NET标准中find一个包，所有的传递依赖关系可以在你的目标平台上运行。 我怀疑没有太多的软件包可以符合这个法案。