Azure Pipeline Nuget Package Versioning Scheme, How to Get "1.0.$(Rev:r)"

Question

I'm setting up an Azure Pipelines build that needs to package a C# .NET class library into a NuGet package.

In this documentation, it lists a couple different ways to automatically generate SemVer strings. In particular, I want to implement this one:

$(Major).$(Minor).$(rev:.r), where Major and Minor are two variables defined in the build pipeline. This format will automatically increment the build number and the package version with a new patch number. It will keep the major and minor versions constant, until you change them manually in the build pipeline.

But that's all they say about it, no example is provided. A link to learn more takes you to this documentation, where it says this:

For byBuildNumber, the version will be set to the build number, ensure that your build number is a proper SemVer e.g. 1.0.$(Rev:r). If you select byBuildNumber, the task will extract a dotted version, 1.2.3.4 and use only that, dropping any label. To use the build number as is, you should use byEnvVar as described above, and set the environment variable to BUILD_BUILDNUMBER.

Again, no example is provided. It looks like I want to use versioningScheme: byBuildNumber, but I'm not quite sure how to set the build number, I think it pulls it from the BUILD_BUILDNUMBER environment variable, but I can't find a way to set environment variables, only script variables. Furthermore, am I suppose to just set that to 1.0.$(Rev:r), or to $(Major).$(Minor).$(rev:.r)? I'm afraid that would just interpret it literally.

Googling for the literal string "versioningScheme: byBuildNumber" returns a single result... Does anyone have a working azure-pipelines.yml with this versioning scheme?

Answer 1

Working YAML example for Packaging/Versioning using byBuildNumber

NOTE the second parameter of the counter - it is a seed value, really useful when migrating builds from other build systems like TeamCity; It allows you to set the next build version explicitly upon migration. After the migration and initial build in Azure DevOps, the seed value can be set back to zero or whatever start value (like 100) you may prefer every time majorMinorVersion is changed:

reference: counter expression

name: $(majorMinorVersion).$(semanticVersion) # $(rev:r) # NOTE: rev resets when the default retention period expires

pool: 
  vmImage: 'vs2017-win2016' 

# pipeline variables
variables:
  majorMinorVersion: 1.0
  # semanticVersion counter is automatically incremented by one in each execution of pipeline
  # second parameter is seed value to reset to every time the referenced majorMinorVersion is changed
  semanticVersion: $[counter(variables['majorMinorVersion'], 0)]
  projectName: 'MyProjectName'
  buildConfiguration: 'Release'

# Only run against master
trigger:
- master

# Build
- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    projects: '**/*.csproj'
    arguments: '--configuration $(BuildConfiguration)'

# Package
- task: DotNetCoreCLI@2
  displayName: 'NuGet pack'
  inputs:
    command: 'pack'
    configuration: $(BuildConfiguration)
    packagesToPack: '**/$(ProjectName)*.csproj'
    packDirectory: '$(build.artifactStagingDirectory)'
    versioningScheme: byBuildNumber # https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#yaml-snippet

# Publish
- task: DotNetCoreCLI@2
  displayName: 'Publish'
  inputs:
    command: 'push'
    nuGetFeedType: 'internal'
    packagesToPush: '$(build.artifactStagingDirectory)/$(ProjectName)*.nupkg'
    publishVstsFeed: 'MyPackageFeedName'