VSTS/Azure DevOps: Auto-Increment NuGet Package Version on Pack

If you're just looking to bump the major, minor or revision version number, using counter operator in a variable is a simple and elegant approach. It will automatically add one to the current value.

Here's what I use:

variables:
  major: '1'
  minor: '0'
  revision: $[counter(variables['minor'], 1)] #this will get reset when minor gets bumped. The number after Counter is the seed number (in my case, I started at 1).
  app_version: '$(major).$(minor).$(revision)'

If you would like to see a real-world 4-job pipeline that uses this, I have one here https://github.com/LanceMcCarthy/DevReachCompanion/blob/master/azure-pipelines.yml

For me it's enough to set Build number format on Options tab to

$(date:yyyy).$(date:MMdd)$(rev:.r) 

and add next build argument:

/p:Version=1.$(Build.BuildNumber) /p:AssemblyVersion=1.$(Build.BuildNumber)

In this case we manage major version manually, but minor version and build number will be set automatically. Easy to understand what version you have deployed.

From the docs, the variable Rev:.r is the daily build revision count. The accepted "solution" would lead to one day finishing having a version of 1.0.12, then the next day it will be 1.0.1.

If you want a simple incremental and unique semver, use 1.0.$(BuildID).

$(BuildID) is an internal immutable counter for your builds, and thus far cleaner than $(BuildNumber).

---

BuildID will always be incrementing - no reset. Thus after a minor bump, you'd end up having say 1.2.123 becoming 1.3.124.

If you want to perform this task well, this can be done using npm version or similar, such as pubspec_version for Dart or Flutter builds.

- script: npm version $RELEASE_TYPE

where $RELEASE_TYPE is a variable you can set based on build (ie: CI, PR etc), having a value of major, minor, patch, prerelease etc.

- script: npm version $RELEASE_TYPE
  condition: startsWith(variables['build.sourceBranch'], 'refs/head/release/')
  env:  
    releaseType: minor

---

Update: Bump Repo Version and Use In Build (using npm)

To have the repo version update, I ended up including npm version as a DevDependency, with it's precommit hook to bump the project version on any commit.

This technique can be applied to other project types, placing them in a subfolder - although can lead to complications with server OS requirements.

To use this version in your build, add this bash script task, which gets and exports the version as a task variable:

v=`node -p "const p = require('./package.json'); p.version;"`
echo "##vso[task.setvariable variable=packageVersion]$v"

---

.Net Core Task only version

Unfortunately, no repo-bump.

Workaround 1:

jobs:
  - job: versionJob #reads version number from the source file
    steps:
      - powershell: |
          $fv = Get-Content versionFile
          Write-Host ("##vso[task.setvariable variable=versionFromFile;isOutput=true]$fv")
        displayName: 'version from file' 
        name: setVersionStep  


  - job: buildJob # consumes version number, calculates incremental number and set version using assemblyinfo.cs
    dependsOn: versionJob
    variables:
      versionFromFile: $[ dependencies.versionJob.outputs['setVersionStep.versionFromFile'] ] # please note that spaces required between $[ and dependencies
      buildIncrementalNumber: $[ counter(dependencies.versionJob.outputs['setVersionStep.versionFromFile'],1) ] #can't use $versionFromFile here


    steps:
      - powershell: |
          Write-Host ($env:versionFromFile)
          Write-Host ($env:versionFromFile + '.' + $env:buildIncrementalNumber)
        displayName: 'version from file output' 

Workaround 2:

This post describes a couple of others, using version-prefix and automatically applying the BuildNumber as a version-suffix.

I may have figured it out. For anyone tearing their hair out, try this:

Pack Task:

• Automatic Package Versioning: Use an environment variable
• Environment variable: Build.BuildNumber

Then, up in the top menu where you have Tasks, Variables, Triggers, Options, click Options and set:

• Build number format: 1.0$(Rev:.r)

Save and queue. This will produce e.g. 1.0.1.

(Please Correct me if I am wrong, or if this does not work long-term.)