Publishing NuGet packages to a private Azure Artifacts feed with YAML Build files

We can publish NuGet packages to internal feeds hosted in Azure Artifacts easily via pipelines defined in YAML files.

Using Azure Artifacts, we can publish NuGet packages to a private (or public) NuGet feed. These feeds can be scoped in Azure DevOps at either an organization level or at a project level.

Creating a private NuGet feed in Azure DevOps is really simple. This article below shows have you can set one up. If you’re following along and you haven’t set up an internal feed yet, stop reading this article and check out the article here. Once you’re done with that, you can return here.

This post will show you how we can use a YAML build file to publish the NuGet packages we create to our own Private feeds in Azure Artifacts.

Now you might have an opinion on YAML in general and yes, we can achieve the same result via the Classic user interface, but I like being able to include our build files within our code repository and providing me with the ability to check the history of our build file using the git history of that YAML file.

To publish our NuGet package to our internal feed, we need to do the following:

• Create our NuGet package.
• Decide our versioning strategy for our package.
• Publish our package to our Internal Feed.

For this post, I’m going to be using a helper library that I’ve been using for my own health application. If you want to have a look at it while reading this (it includes the YAML file), check it out here.

Creating our NuGet Package

Before jumping into the meat of our build file, We need to set some things up:

Let’s break this down:

• We trigger the build to kick off every time we make a commit to our main branch.
• We set some common variables that we will need throughout our build pipeline.
• We’re using a Linux image as our build agent.
• We then install the .NET Core SDK on our build agent, restore our project using a DotNetCoreCLI task that runs the restore command, then we build the project using another task that runs the build command.

To create a NuGet package in our build file, we need to add a DotNetCoreCLI task like so:

In this task, we are running the pack command and telling the task to pack our project path that I’ve defined earlier in the YAML file. I’ve set the nobuild argument to true since I’ve already built my project.

My package is a .NET Standard package. For .NET Core and .NET Standard packages, Microsoft recommends that you use the DotNetCoreCLI tasks. If you’re building packages for .NET Framework, you can use a NuGet task.

Versioning Strategy

There are a couple of ways we can do this. In my package .csproj file, I’ve specified my Version number like so:

If we wanted to achieve this via a build task defined in YAML, we can do so like this:

With the NuGet task, we can use the Major.Minor.Patch semantic versioning scheme for our builds. However, once a version has been produced, we can’t update or replace that version. They are immutable. To produce new versions of our package each time we update them, we can do the following:

1. Use the $(rev:.r) variable for the version number that we wish to increment. This will automatically increment the build number for that variable each time we push to our branch, while keeping the other variables constant.
2. Use the $(date:yyyyMMdd) variable. This is ideal for creating prelease labels for the build, while allowing us to keep our major, minor and patch versions constant.

Publishing our package to the feed

Now that we have a package, we can publish it to our feed. In order to publish to our Azure Artifacts feed, we’ll need to set the Project Collection Build Service identity to be a Contributor on the feed.

Once we have enabled that, we can add the following YAML to our build pipeline:

Here, we using NuGetAuthenticate command to authenticate our Build server to push packages to our internal NuGet feed. We then run a NuGetCommand task with the push command to push our package (stored in our Artifact Staging Directory) to our internal NuGet feed.

Here, we have used / as our VSTS feed to publish to. Remember we can scope our feeds at either the project level or at an organization level in Azure DevOps. Since my feed is scoped at the project level, I need to put the project name here.

I’ve also included the nuGetFeedType argument and stated that our target field is an internal feed. Since we are using the push command in the NuGet command task, this argument is required.

Full YAML file

Here’s our complete YAML file:

Conclusion

Hopefully you can see how simple it is to publish our NuGet packages to a private NuGet feed in Azure Artifacts. This isn’t just limited to private NuGet feeds, we can also publish packages from DevOps to NuGet.org.

If you want to learn more about Azure Artifacts, I recommend that you check out the documentation that covers topics such as configuring feeds, publish NuGet (and other) types of packages and more.

If you have any questions about this article, please let me know in the comments or you can reach out to me on Twitter.