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.
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.
Add a variable named buildNumber in the build definition.
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
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.
Notice: there should be a space [ ] before
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