Continuous Delivery of your NuGet Packages with VSTS – SemVer

This post is a continuation of my first post on the topic of NuGet packages.  This post, however, will focus on using Semantic Versioning of your NuGet packages.  The previous post published a NuGet package and used the Package Management Views in VSTS to demonstrate the quality of the package as it moved through the Release Pipeline.

The process to do the Semantic Versioning is similar to the first one with a few exceptions:

  1. The Build Definition no longer executes the NuGet Pack task (this is done during release)
  2. The Artifacts that are produced by build includes everything we need to execute the NuGet Pack task (binaries, .nuspec, scripts, etc.)
  3. Semantic Versioning 2.0.0 support requires NuGet 4.3.0 or higher, you can see the other requirements documented here.
  4. Version numbers do not support leading zeros.  Why is this important? The build number format must not use $(Rev:.rr) or else we will violate the spec and the NuGet pack command will fail.

    If we take a look at the relevant part of the SemVer 2.0 spec:

    A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

    A pre-release version MAY be denoted by appending a hyphen and a series of dot-separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

Now that we have that out of the way here is the build definition I have modified from my previous post:

Disabled NuGet Pack task


Disable the NuGet pack command as part of build

Copy all files required to create a NuGet package during the release pipeline


Copying all project files, including .nuspec

Note this Copy **\*  may not be practical in a production environment in which case you could just list the specific folders and files required (just remember the file paths in your .nuspec).  Here is a much better example suited to real life DevOps:


We only copy what we need to execute NuGet pack


Fix the Build Number Format so we don’t throw an error when we execute NuGet pack


Make sure you have no leading zeros in your Build Number Format string

Now given we have done all of that we should be able to kick off a build to make sure we have all our required artifacts.  We also want to ensure we have no leading zeros in our version number, we do not so we can continue to our new release definition.


Artifacts Explorer – Make sure we got all our files


The Release Definition to Publish Packages using Semantic Versioning

In this example I have four (4) environments (alpha, beta, prerelease, production) that represent the prerelease and production of my NuGet package


The first environment is triggered immediately after the build is completed and creates a NuGet package with an alpha prerelease version. Example: 1.0.0.alpha.1

Here is a list of the tasks the Agent exucutes in each environment shown above:

  • NuGet Tool Installer (we require v4.3.0 or higher)
  • Execute PowerShell Script (this updates the version element in the .nuspec)
  • NuGet (we execute NuGet pack to build our .nupkg)
  • NuGet (we execute NuGet push to publish our package to the VSTS package feed)
  • Execute PowerShell Script (this puts the package into the appropriate View based on the environment name)

Here are some screen captures for each of the tasks:



NuGet Tool Installer


Execute ApplyVersionToAssemblies.ps1



NuGet pack


NuGet push


Execute Set-PackageQuality.ps1


If we look at the Release of one of the Environments (Beta) we can see that all steps were successful:


This is showing the output from the NuGet push task

Here is the output which shows the package version that was published to out feed:

2018-03-17T19:04:49.2932124Z ##[section]Starting: NuGet push
2018-03-17T19:04:49.2937456Z ==============================================================================
2018-03-17T19:04:49.2937590Z Task : NuGet
2018-03-17T19:04:49.2937809Z Description : Restore, pack, or push NuGet packages, or run a NuGet command. Supports and authenticated feeds like Package Management and MyGet. Uses NuGet.exe and works with .NET Framework apps. For .NET Core and .NET Standard apps, use the .NET Core task.
2018-03-17T19:04:49.2937989Z Version : 2.0.21
2018-03-17T19:04:49.2938103Z Author : Microsoft Corporation
2018-03-17T19:04:49.2938213Z Help : [More Information](
2018-03-17T19:04:49.2938329Z ==============================================================================
2018-03-17T19:04:49.9083924Z [command]C:\Windows\system32\ 65001
2018-03-17T19:04:49.9084369Z Active code page: 65001
2018-03-17T19:04:49.9086750Z SYSTEMVSSCONNECTION exists true
2018-03-17T19:04:49.9087030Z Detected NuGet version / 4.5.0
2018-03-17T19:04:50.6199934Z Saving NuGet.config to a temporary config file.
2018-03-17T19:04:50.6271979Z ##[warning]No package sources were found in the NuGet.config file at D:\a\r1\a\Nuget\tempNuGet_1232.config
-Source -AccessToken ******** -NonInteractive -Verbosity Detailed
2018-03-17T19:05:00.9137246Z Trying to authenticate with auth token.
2018-03-17T19:05:00.9137814Z Successfully authenticated.
2018-03-17T19:05:00.9138077Z Authentication and request took 00:00:04.9081141
2018-03-17T19:05:00.9138383Z Adding package ContosoLogger.Library.0.1.18076-beta.1.nupkg to feed 38fdd1ec-29da-4fd2-8179-c8df385b3532 on
2018-03-17T19:05:00.9138645Z Trying to add package to feed without uploading.
2018-03-17T19:05:00.9138844Z Adding package to feed.
2018-03-17T19:05:00.9139085Z The package content is not already on the service.
2018-03-17T19:05:00.9139285Z Uploading package content.
2018-03-17T19:05:00.9139822Z Done uploading package content.
2018-03-17T19:05:00.9140135Z Adding package to feed.
2018-03-17T19:05:00.9140337Z Successfully added package to feed.
2018-03-17T19:05:00.9347185Z ##[section]Finishing: NuGet push

VSTS Packages

We will find this package in the Beta view because of the Set-PackageQuality.ps1 script.

Package View (Beta)


Visual Studio NuGet Package Manager

If we take a look at Visual Studio in the NuGet package manager we can see the release and prerelease versions of our NuGet package



Sample NuGet Package with Release and Prerelease versions


Hope you find this useful and if you have any feedback let me know.


About Wes MacDonald

Wes MacDonald is a Visual Studio ALM MVP, PSD, MCT and a Principal Consultant for LIKE 10 INC., a SharePoint Server, Visual Studio and Team Foundation Server Consulting Firm providing premium support and guidance services.

2 Responses to “Continuous Delivery of your NuGet Packages with VSTS – SemVer”

  1. what happens to the alpha package when it is propagated to beta?
    any projects using the alpha package will than fail if it is no longer available locally in the project and the NuGet setting not allowing to upgrade the verison.
    Especially you would no longer be able to build an older version of your application to verify a bug because it is no longer buildable.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: