对于C#和VB项目文件，Microsoft在尝试推出基于JSON的项目格式后，又回归到以MSBuild为基础。在推出此决策的同时，Microsoft承诺会实现一些十分类似于project.json的特性。今天我们将探讨其中的一个特性：NuGet集成。

一直以来，NuGet都是一个附加（bolt-on）在Visual Studio中的特性。但是编译器虽然可以触发NuGet软件包的下载，却无法理解这些软件包。因此当一个软件包完成下载后，需要被安装到项目之中，其中可能包括更新装配引用（Assembly Reference）、拷贝文件或是运行定制的PowerShell脚本。这一做法是非常脆弱的，开发人员时常需要在重新安装软件包前手工清理项目文件。

随着这一新特性的提出，很多类似的问题将不再出现。现在开发人员不再是引用个别的装配，而是可以引用软件包本身。

包引用现在是可传递的。这意味着你仅需引用一个软件包即可，不再需要显式地引用该软件包所需的各个软件包。按新闻发布稿中的说法，这可提升安装或更新软件包的性能达五倍。在一个例子中，一个10分钟的过程降低到了30毫秒。

NuGet集成特性取消了解决方案层面的包文件夹，依赖将直接引用用户的“Package Cache”目录。要解释为什么Microsoft以前不这样，让我们重新回顾一下以前版本NuGet的“附加性”本质。鉴于编译器不能理解NuGet软件包，因此需要在项目文件中正确设置一个“路径线索”。由于每个用户可以设置自身的“Package Cache”目录，因此不能使用这样的文件夹，需要创立解决方案层面的包文件夹，以确保相对的路径线索对于所有的开发人员都是一样的。

版本控制

对NuGet项目引用的版本控制支持得到了很大的改进。现在可以使用范围和通配符指定想要使用的软件包版本信息。范围定义采用了数学中的通用语法：

• 不低于x.y版本：[x.y；\\t
• 高于x.y版本：(x.y；\\t
• 不高于x.y版本：x.y]；\\t
• 低于x.y版本：x.y)。\

举个例子，如果你需要版本不低于1.4.2同时不高于1.5，可以使用“[1.4.2, 1.5)”。反之，如果你想要1.4版本家族中的所有版本，可以使用“1.4.*”。

现在可以使用IncludeAssets和ExcludeAssets标签控制内容。它们已被包括在构建过程中，用于修改资产的类型（分析器、内容文件等）。你甚至可以将资产标记为私有的，这意味着其所标记的资产是用于开发目的，不应该留给下游的软件库。

使用MSBuild创建NuGet软件包

虽然在MSBuild中总是可以使用Exec命令加载NuGet的package命令，并传入到规格文件中，但是在持续集成环境中最好不要这样使用。因此这次发布版本实现了MSBuild直接打包项目，甚至适用于使用TargetFrameworks标签定义了多个目标架构的项目。

谈及这个问题，可能存在对不同的目标平台应引用不同的软件包这一需求。你可以使用PackageReference定义一个标准的MSBuild条件表达式，以表示引用的适用场景。

向后兼容问题

对NuGet集成特性的一个主要担心是缺乏对一些旧版本NuGet特性的支持，例如内容文件夹（Content Folder）、XML文档转换（XDT），还有PowerShell脚本install.ps1和uninstall.ps1。

当前这些NuGet特性对于.NET Core和.NET标准项目是可用的。如果安装了，其它类型的项目也可以使用NuGet集成特性。

查看英文原文：

感谢对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（微信号：）关注我们。