NuGet 已整合到 MSBuild 中

  • Jonathan Allen
  • Rays

2017 年 4 月 12 日

话题:.NET持续集成语言 & 开发

对于 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 集成特性。

查看英文原文:NuGet is Now Part of MSBuild


感谢冬雨对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

.NET持续集成语言 & 开发