People familiar with the. NET framework knows that we can let the compiler self-increase the version number by specifying AssemblyVersion as 10.0.*. But. NET core and. NET Standard are not. Even with open-source projects like MSBump, there are certain flaws. Typically, such a requirement happens on a CI/CD server. Let's take a look at how to easily handle it with Azure DevOps.

About Versioning in .NET Core Applications

I have wrote a post on the. NET Core Application Version number: https://edi.wang/post/2018/9/27/get-app-version-net-core

We're going to control Version field this time.

Use dotnet build to compile your application into dll files, and this version will be shown in the property window.

But actually, the build command can have a parameter that sets a specific version number, like this:

dotnet build /p:Version=10.0.8888.1234

Based on this, we can control the build number for a .NET Core application on build servers.

Why Not Use MSBump

You may heard of a project: Msbump, which can also be used to change the version number at compile time. However, it modifies the csproj file at compile time and is a code change. The traditional. NET FX compilation system does not change the code. This is unacceptable to me because it is a kind of uncontrollable factor. It's not a good practice to check in the csproj file that just changed the version number. And instead of generating the version number based on the timestamp, MSBump by default, generates the version by the current version string in the project file. So in a development team, everyone could have inconsistent version of the same csproj file. So I decided to give up MSBump and try to use Microsoft's own technology to solve it's own problem.

Automatically Generate Version Numbers

In a fully automated CI environment, it is not possible for us to manually specify a version number each time. I need a rule and a method to generate it automatically.

The rules I personally use is: [Major].[Minor].[Number of days from January 1, 2000].[Lucky Number]

I use PowerShell to calculate the number of days from 1/1/2000.

$baseDate = [datetime]"01/01/2000"
$currentDate = $(Get-Date)
$interval = NEW-TIMESPAN –Start $baseDate –End $currentDate
$days = $interval.Days

Configure Azure DevOps

We basically need to tell Azure DevOps to calculate the version number, and use /p:Version parameter to build our project.

Environment variables

Add a variable named buildNumber in the build definition.

PowerShell Task

Add a PowerShell Task and put it as the first step in the build pipeline. This PowerShell Task need to calculate the version number and assign it to buildNumber variable

To set value to a variable in Azure DevOps pipeline, use Write-Host as:

##vso[task.setvariable variable=variableName]variableValue

Then, our script will be

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"

Choose Inline and copy this script to the textarea.

Modify .NET Core Task Parameter

Append this to the Arguments filed of both Build and Publish steps.

/p:Version=$(buildNumber)

Notice: there should be a space [ ] before /p

Compile and Done

Trigger a new build, you can see the version number is being set in the build log

and the application will have an updated version after deployment