Managing nuget versions from beta to release in VS2017 for .net core2.1 when building pipeline in Azure Devops

Question

I need to create nuget package for a .net core 2.1 as part of build and release process in Azure Devops What I would like to do

1) In the build section build the project and then add the compiled code to artifact

2) In Release definition will have 2 deployments one for Beta release where the version will be like 1.2.3-Beat.2 and push to azure artifact nuget and another deployment to release where the version will be like 1.2.3.2 and push to azure artifact nuget.

Currently I have only one build definition which will build (nuget package gets created during build process) and push to azure artifact nuget.

Pipeline I would like to create

Josh Gust Josh Gust · Accepted Answer · 2019-02-22T00:29:47

Use the dotnet pack task with the --no-build option, and in your pre-release stage set the VersionSuffix value.

Note: My current team uses a set of Powershell scripts to append build number data to the Major.Minor data found in the .csproj (or AssemblyInfo.cs for netFramework), but that doesn't change the answer to your question. Once you figure out what the Major.Minor.Patch[.Build] data is going to be, you can use the VersionSuffix property in a dotnet pack task with --no-build to communicate quality of the package as it moves through your pipeline.

Given a .csproj file that looks like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>
  <PropertyGroup>
    <PackageVersion>1.0.0.1</PackageVersion>
    <AssemblyVersion>1.0.1812.201</AssemblyVersion>
    <FileVersion>1.0.1812.201</FileVersion>
  </PropertyGroup>
  <ItemGroup>
    <Content Include="Assemblies\*">
      <Pack>true</Pack>
      <PackagePath>lib\$(TargetFramework)</PackagePath>
    </Content>
  </ItemGroup>
</Project>

Again, if we ignore the versioning step that we use, the dotnet pack task in the pipeline image above will produce a package with the version 1.0.0.1-Beta.

Then in your stable release stage, don't set the suffix value and let the package get its version from the .csproj file like normal (eg. 1.0.0.1).

The elements and values in the sample .csproj file above can be written as direct edits to the .csproj or they can be set using the Properties >> Package tab.

If the values are not changed in the properties menu or added explicitly, the elements and values do not appear in the .csproj and are assumed by dotnet build|test|pack commands.

Finding the right combination of these properties and values can be daunting if you aren't familiar with how they're fitted together. I found this article useful when trying to decipher the version properties.

Also, you should understand 1.0.1-b2 < 1.0.1, so your pre-release version might be 1.2.3.2-beta1 and your stable version would be 1.2.3.2.

Managing nuget versions from beta to release in VS2017 for .net core2.1 when building pipeline in Azure Devops

2 Answers