为什么我的.NET Standard 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标准中< 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中修复此问题.