对于C#和VB项目文件，Microsoft在尝试推出基于JSON的项目格式后，又回归到以MSBuild为基础。在推出此决策的同时，Microsoft承诺会实现一些十分类似于project.json的特性。今天我们将探讨其中的一个特性：NuGet集成。
一直以来，NuGet都是一个附加（bolt-on）在Visual Studio中的特性。但是编译器虽然可以触发NuGet软件包的下载，却无法理解这些软件包。因此当一个软件包完成下载后，需要被安装到项目之中，其中可能包括更新装配引用（Assembly Reference）、拷贝文件或是运行定制的PowerShell脚本。这一做法是非常脆弱的，开发人员时常需要在重新安装软件包前手工清理项目文件。
随着PackageReference这一新特性的提出，很多类似的问题将不再出现。现在开发人员不再是引用个别的装配，而是可以引用软件包本身。
包引用现在是可传递的。这意味着你仅需引用一个软件包即可，不再需要显式地引用该软件包所需的各个软件包。按新闻发布稿中的说法，这可提升安装或更新软件包的性能达五倍。在一个例子中，一个10分钟的过程降低到了30毫秒。
NuGet集成特性取消了解决方案层面的包文件夹，依赖将直接引用用户的“Package Cache”目录。要解释为什么Microsoft以前不这样，让我们重新回顾一下以前版本NuGet的“附加性”本质。鉴于编译器不能理解NuGet软件包，因此需要在项目文件中正确设置一个“路径线索”。由于每个用户可以设置自身的“Package Cache”目录，因此不能使用这样的文件夹，需要创立解决方案层面的包文件夹，以确保相对的路径线索对于所有的开发人员都是一样的。
版本控制
对NuGet项目引用的版本控制支持得到了很大的改进。现在可以使用范围和通配符指定想要使用的软件包版本信息。范围定义采用了数学中的通用语法：
不低于x.y版本：[x.y； 高于x.y版本：(x.y； 不高于x.y版本：x.y]； 低于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标准项目是可用的。如果安装了VS 2017 Update 1预览版，其它类型的项目也可以使用NuGet集成特性。
本文转自d1net（转载）
