Publishing NuGet packages to a private Azure Artifacts feed with YAML Build files
Tags: azure, devops, dotnet
Published: 2021-05-02 04:36:15

---
title: Publishing NuGet packages to a private Azure Artifacts feed with YAML Build files
published: true
description: We can publish NuGet packages to internal feeds hosted in Azure Artifacts easily via pipelines defined in YAML files.
tags: azure,devops,dotnet
//cover_image: https://direct_url_to_image.jpg
---
We can publish NuGet packages to internal feeds hosted in Azure Artifacts easily via pipelines defined in YAML files.

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xefx05tb8n01lgnjj3fe.png)

[Using Azure Artifacts](https://docs.microsoft.com/en-us/azure/devops/artifacts/?view=azure-devops), 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](https://docs.microsoft.com/en-us/azure/devops/artifacts/get-started-nuget?view=azure-devops&tabs=windows). 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](https://github.com/willvelida/MyHealth.Common).

**Creating our NuGet Package**

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

{% gist https://gist.github.com/willvelida/3bca5cab42c23f4bdfabfabcdeed2b1a %}

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:

{% gist https://gist.github.com/willvelida/5d1cf66988f3357842558781a4979e13 %}

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:

{% gist https://gist.github.com/willvelida/eea7290d16c5ab366157a2d26e786f04 %}

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

{% gist https://gist.github.com/willvelida/e8d7d8c397a1fe46e03cedd111f74fbd %}

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](https://docs.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions?view=azure-devops#azure-artifacts-settings).

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

{% gist https://gist.github.com/willvelida/806d5e2a3340ceccb0dfbebb36f583a5 %}

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 *<projectname>/<feedname>* 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:

{% gist https://gist.github.com/willvelida/fc545b211e8ae8c870fb14ad882ec688 %}

**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](https://docs.microsoft.com/en-us/azure/devops/artifacts/?view=azure-devops) 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](https://twitter.com/willvelida).