如何正确构造netstandard1.0 NuGet包的依赖关系?

问题描述:

我更新了配置文件259到.NET Standard 1.0的PCL,并且想要相应地更新相应的NuGet包。我将包含实际DLL的文件夹从portable-net45+win8+wp8+wpa81更改为netstandard1.0,但我不太确定如何构建包的依赖关系。如何正确构造netstandard1.0 NuGet包的依赖关系?

如果我使用.NET的核心CLI来创建一个包(dotnet pack),在nuspec文件的依赖关系部分只是看起来是这样的:

<dependencies> 
    <group targetFramework="netstandard1.0"> 
    <dependency id="NETStandard.Library" version="1.6.0" /> 
    </group> 
</dependencies> 

然而,当我这个包安装到一个经典之作。 NET 4.5或仍使用packages.config PCL项目,那么这个文件被“污染”从NETStandard.Library元数据包的所有依赖关系,就像这样:

"polluted packages.config file containing all the dependencies from NETStandard.Library 1.6.0

  1. 这不应该被避免吗?一种方法是在nuspec文件as suggested by Oren Novotny on the GitHub page of NuSpec.ReferenceGenerator中创建空的依赖关系组。但是,他自己在one of his recent blog posts中不赞成这一点。
  2. 我应该瞄准整个NETStandard.Library元包或者只是我实际需要的包?是不是.NET Standard/.NET Core可以轻松在支持包的依赖关系的所有平台上运行?

不幸的是,带有.NET Core/.NET Standard的NuGet包的official documentation尚未编写。

我不得不解决这个问题,我维护的目标都是.NET Core和.NET 4.5。这种方法我用你的问题的两个点触摸:

  1. 在project.json,分裂依赖性起来netstandard1.Xnet45之间。最初,使用NETStandard.Library metapackage使前者变得容易。
  2. NETStandard.Library替换为我实际需要的特定软件包的引用。

在第一步中,我project.json看起来是这样的:

{ 
    "dependencies": { 
     "MyOtherLibrary": "1.0.0" 
    }, 
    "frameworks": { 
     "net45": { 
     "frameworkAssemblies": { 
      "System.Collections":"4.0.0.0" 
     } 
     }, 
     "netstandard1.3": { 
     "dependencies": { 
      "NETStandard.Library": "1.6.0" 
     } 
     } 
    } 
} 

任何依赖关系本身已经有两种框架兼容进去dependencies,而具体的.NET的核心,或者.NET 4.5依赖关系根据需要进入各自的部分。

随着dotnet pack,这将产生正是我需要的:一个.nupkg,可以安装在任何类型的项目,并仅在它需要在该框架拉。

在第二步中,我换出NETStandard.Library与我实际需要.NET核心的几个包:

{ 
    "dependencies": { 
     "MyOtherLibrary": "1.0.0" 
    }, 
    "frameworks": { 
     "net45": { 
     "frameworkAssemblies": { 
      "System.Collections":"4.0.0.0" 
     } 
     }, 
     "netstandard1.3": { 
     "dependencies": { 
      "System.Threading.Tasks": "4.0.11", 
      "System.Net.Http": "4.1.0" 
     } 
     } 
    } 
} 

这第二个步骤是没有必要的,但它是很好的产生具有最小的依赖包为这两个平台。 NETStandard.Library在开发阶段非常有用,当你不太清楚你需要在核心API中使用什么。