• Azure DevOps搞定.NET Core编译版本号自增
  • 发布于 2个月前
  • 322 热度
    0 评论
  • 噪音
  • 0 粉丝 8 篇博客
  •   

熟悉.NET Framework的人知道,我们可以通过指定AssemblyVersion为10.0.*来让编译器自增版本号。但是.NET Core和.NET Standard不行。即使有MSBump这样的开源项目,也有一定的缺陷。一般这样的需求会出现在CI/CD服务器上。我们来看看如何用Azure DevOps轻松搞定。


关于.NET Core应用版本号

先看一张图

就是它
使用.NET Core CLI的build命令直接编译出来的DLL会显示这个版本。

但其实,build命令是可以加参数的,想要在不更改csproj文件的情况下build一个自定义版本可以加个/p参数,指定Version,这样搞:
dotnet build /p:Version=10.0.8888.1234

基于这个原理,我们就能控制.NET Core应用程序在编译环境的版本号。


为毛不用 MSBump

可能有朋友知道这么一个项目:MSBump,也能用来在编译时改变版本号。但是,它在编译时候会去改csproj文件,对于代码来说是一次更改。而传统.NET Fx的编译系统不会改代码。这对于我来说是无法接受的,因为引入了不可控的因素。在多人团队本地build完竟然还要签入仅仅是更改了版本号的csproj文件,不是一种好方法。并且它的默认规则,不是根据时间戳来增加版本号的,而是根据本机当前工程文件的版本。所以在多人协作的代码库里对导致版本混乱。因此我决定放弃MSBump,尽量用微软自家技术,解决自家问题。


自动生成版本号
在全自动的CI环境,我们不可能每次手工干预指定版本号。我需要一种规则和方法去生成每次都不一样,并且一眼就能判断新旧的版本号。
我个人使用的规则是:主.次.距2000年1月1日的天数.幸运数字
其中要计算的是距2000年1月1日的天数。可以用Windows计算器按出来,也可以写程序算。但在自己动手造轮子之前,一个好习惯是看看微软是否已经有现成的工具可以完成。当然,微软一定是有的:PowerShell
PowerShell计算两个日期之间相差的天数,非常简单:
$baseDate = [datetime]"01/01/2000"
$currentDate = $(Get-Date)
$interval = NEW-TIMESPAN –Start $baseDate –End $currentDate
$days = $interval.Days


配置 Azure DevOps
有了以上的知识。我们要做的,就是让Azure DevOps在编译时,自动计算出版本号,然后给build命令加上/p:Version参数。怎么做呢?很简单!
环境变量
首先,我们需要一个变量,比如叫做 buildNumber
在编译定义的variables里可以添加。随便指定一个版本号就行。

PowerShell 任务
我们要使用PowerShell计算版本号,并给刚才那个 buildNumber 变量赋值。所以,添加一个PowerShell任务,放在最前面。

给Azure DevOps编译管线里的变量赋值,有个神奇的技巧,就是用Write-Host就可以了:
##vso[task.setvariable variable=变量名称]变量值
所以最终我们的脚本是
Write-Host "Generating Build Number"
$baseDate = [datetime]"01/01/2000"
$currentDate = $(Get-Date)
$interval = NEW-TIMESPAN –Start $baseDate –End $currentDate
$days = $interval.Days
Write-Host "##vso[task.setvariable variable=buildNumber]10.0.$days.1024"

在任务属性里选择inline,复制粘贴了这段代码。 //能跑就行,实在不行,删库跑路,也挺省心。

更改.NET Core任务参数
在Build及Publish任务的Arguments后面都加上:
/p:Version=$(buildNumber)
注意/p的前面有个空格

重跑编译,大功告成
触发一个CI/CD管线,可以看到日志中已经输出了正确的版本和参数。

并且部署完后,也能得到正确的版本了:

用户评论