但是当我尝试将我的项目(通过NuGet)添加到一个新的.NET Framework 4.6项目时,依赖关系解析为47个包！它们都是系统库,似乎是Microsoft.NETCore.Platforms或NETStandard.Library 1.6.1的依赖项. (Gist of full PM output.)
我的项目只导入(使用)一些库,我没有手动添加;即他们都是“随.NET标准附带”的图书馆.这些库是：
>系统
> System.Text
> System.Reflection
> System.Linq
> System.Collections.Generic;
问题是,我决定让我的项目成为.NET Standard,因为我希望它能够跨.NET Framework和.NET Core应用程序无缝地工作.我认为标准的重点是设置最低级别的兼容性.通过扩展,我想我曾(或许是错误地)假设像System.Console这样的库可以在Core或Framework中自动使用.
当我在同一个解决方案中测试我的Standard项目作为Framework和Core项目中的依赖项时,我没有注意到这样的事情,所以我怀疑这可能是一个NuGet的事情.
这里到底发生了什么？如何在没有大量依赖项的情况下在NuGet上提供我的.NET标准库？
这是我指定我的NuGet包的方式有问题吗？或者我从根本上误解了什么？
您所看到的是.NET Standard的构建方式以及对支持的框架的支持的副作用.根据您定位的.NET Standard版本和用于引用库包的工具,这也有所不同.
在.NET标准中< 2.0,您引用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)没有做太多 – 它们只是转发到系统程序集.例如,“contract”定义System.Object是在System.Runtime.dll程序集中定义的.因此,您在.NET Framework应用程序中最终得到的System.Runtime.dll文件包含一个System.Runtime.dll,其中包含转发到.NET Framework的mscorlib.dll类型. .NET Core已经包含一个不同的System.Runtime.dll,它为该平台执行不同的操作.这种机制允许单个DLL文件在两个平台上工作,因为这些类型转发和其他实现确保在两个实现上工作的相同“契约”(类型程序集程序集版本). .NET Standard 2.0旨在减少必需的包和DLL的数量,并且每当发布新的.NET Core版本时,都要删除对.NETStandard.Library的更新. 因此,对于.NET Standard 2.0和.NET Core 2.0,NETStandard.Library包只会将用于编译代码的引用程序集带到项目中,但生成的NuGet包不再依赖于此程序包.因此,当您创建一个面向.NET Standard 2.0并发布它的库时,它将没有NuGet依赖项(除非您添加其他的). 在使用.NET标准库时,“支持库”引入的逻辑被移动到构建期间使用的工具.因此,当包含对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标准实现库.因此,如果您引用.NET Core 1.0发布时构建的.NET Standard 1.0 NuGet包,则会修剪其所有NuGet依赖项,并获得构建工具附带的支持库. 想法是.NET Framework 4.7.1将包含所有必需的程序集“inBox”,以便netstandard.dll,System.Runtime.dll等是.NET Framework的一部分,任何.NET Standard 1.0-2.0 DLL文件都会“只是工作”,问题是这些“收件箱”DLL文件的某些程序集的版本号太低,因此库无法加载 – 这是通过再次更改工具以包含具有更高版本号的DLL文件作为支持库来解决的然后转发到“收件箱”.NET Framework程序集.计划在.NET Framework 4.7.2中修复此问题.
