This blog was originally posted on my website and I thought I might share it here.

Scenario

The scenario for this post is that I have a library hosted on NuGet and whenever I deploy a new package I want to increment the version of the package, but I don’t want to update the assembly information in my project or manually update the version in my build pipeline every time I want to deploy. I want to automate this and ensure that every time I deploy a new version of my library to NuGet the version gets incremented by 1 and I want to do this all inside my pipeline on
Azure DevOps.

For this, I will be creating a new build task that I can plug into my pipeline on Azure DevOps.

Creating Task

In a previous post I showed you how to create your own custom build tasks. I will be doing the same for this task, but the only exception this time around is that I’ll be using PowerShell, as apposed to Node. There is no reason in particular for using PowerShell other than the fact that I am currently in the motions of learning it. Using PowerShell does come with one downside though, and that is the task is not cross-platform as with your node tasks.

The VstsTask SDK does not support PowerShell Core, and does not seem likely to in the near future. You are advised to use Node if you want to create cross-platform tasks.

So once we completed Part 1 of creating our own tasks, I will be implementing the logic. What we want is to get the current version of the library on NuGet.org and increment that value before we pack/publish our library.

Pretty straightforward right?

Implementation

For this version of the task, we are going to require three inputs from the user. We need to know the name of the package we will be working with, that’s the first one. Secondly, we want to increment the Patch version number, but we also do not want to increment it infinitely. For this, we require the user to set an upper limit the Patch version can be incremented to before resetting it to 0 and incrementing the Minor version. We will come back to the third required input later.

Once we have our setup complete we can go ahead and implement the core functionality for this task.

We will use the Find-Package command to find the package on Nuget, or your own locally hosted package manager. Before we do that, we need to add the Nuget package source. The Register-PackageSource command should be called before we execute the Find-Package command because it uses these package sources to search for your package. Once we have our package and the version we can go ahead and update it.

Once we have our new version set, we need to pass it on to the next task in our pipeline, the Nuget Pack command.

Nuget Pack

When packing a Nuget package, the version of the package is required. Nuget does not allow you to publish the same version of a package multiple times. This brings us to the third required input for our task. Once we have our new version, we need to pass it on to the next task in our pipeline. I already have a variable I am using in the pipeline to set the new version of the package, so I figured why not use the same variable. For this to work, I am updating my environment variable from my custom task using the VSTS task.setvariable command. This updates the variable packageVersion to the newly calculated version.

Above is a screenshot of my pipeline for my library. Before the packing stage, I will generate the next version number based on the current version of the package on NuGet, update the packageVersion value which will then be used as the version during the Packing stage that follows.

And there we have it, every time we want to publish our library to NuGet the correct version number will be used.

The source code for this build task can be found at this repository. Stay tuned to this repository as I will be adding more tasks in the future.