Update: This article makes use of the obsolete build pipeline for Azure DevOps. An updated article that makes use of the new YAML scheme is in the works. Follow my profile to be notified.
By using your custom NuGet package feed within your Azure DevOps (previously VSTS) instance, you’ll be able to distribute your packages within your organization with ease.
Here’s everything you need to know. Without any further ado and yada yada, let’s just jump straight into it.
NuGet Packages within Azure DevOps
That’s right. Microsoft offers an official extension for publishing and managing your private NuGet feeds.
It starts from a single DevOps project. From there, you’ll be able to set up various private NuGet feeds and distribute them across your entire organization.
First things first, create a new DevOps project unless you already did and navigate to Packages in the left navigation pane.
In there, create a new feed and choose a sensible name for your feed. You can also specify whether all people in your organization or just specific people will be able to consume (or fully access) your feed.
That’s it. Your feed is ready to use. Well, almost. It’s missing some decent packages and we’ll deal with it now.
Build and Release
The first step we need to do is to set up a build definition for our brand new NuGet package. Let’s assume we’ve already created a new class library based on .NET Core (or .NET Standard) and pushed it to our DevOps Git repository.
Navigate to your build definitions and create a new definition. Select your Git repository and its branch that contains the library you would like to build. Go ahead and apply the “Empty pipeline” template. We’ll start from scratch just to cover all angles.
First of all, we’re using .NET Core here. If you’re using .NET Framework, you’ll need to add steps that are related to its respective framework instead.
Let’s consider all the steps we need to include first:
- Before we build anything, we need to restore all of our library’s dependencies.
- Then, we need to build (and test, whenever applicable) our library.
- Finally, we can publish, pack and push the built project to our NuGet feed.
Select your agent job and add the .NET Core task six times. All tasks are based on it. Also, add the Publish Build Artifact task at the end of your job if you wish to publish an artifact after the build has been completed.
On a side note: I recommend to put it in there, just in case something goes somewhere terribly wrong while Azure DevOps publishes our NuGet package. It makes it easier for us to investigate the build error.
To restore our packages, just rename the display name to “Restore” and select “restore” in the command drop-down list. Keep in mind that you may need to specify the path of your project for all .NET Core tasks, like
Then, select the second .NET Core task, rename it to “Build” and select the “build” command from the list. For the third task, rename it to “Test” and hit the “test” command.
You may also want to disable this step in case you don’t want to test your class library (or in case you haven’t added a unit test project), though leaving it on doesn’t really hurt, in fact, it just won’t trigger if you haven’t created any test projects.
Afterwards, let’s publish our package. To do so, select the fourth .NET Core task, rename it to “Publish” and select the “publish” command. You may also pass additional arguments to it.
Update May 20th, 2019:
When you start with an empty pipeline you may need to go to your pipeline variables and provide a build configuration for this task. You can either choose ‘Debug’ or ‘Release’. If not specified, it’ll always default to Debug. Thank you Kaine Varley for the heads up.
The publish command allows us to copy our project files to a different directory. In this case, we publish it to our default Azure DevOps artifact directory. You can also disable this task if you don’t plan to make use of build artifacts.
Okay, we’re almost halfway there. Now it’s time to define our NuGet tasks.
.NET Core is pretty awesome and is able to deal with NuGet feeds out of the box, both when it comes down to restore and to publish packages.
Select the fifth .NET Core task, rename it to “Pack” and select the “pack” command. Make sure to set the appropriate options as seen here:
You may go for a different automatic package versioning scheme, it fully depends on your workflow and your preferences. You can choose between date and time, an environment variable or the build number. If you turn it off, it’ll use your version number from your project instead. Make sure to keep it up to date just to prevent any build errors or version conflicts upon publishing your feed.
Almost there, now it’s time to push the package. Select the last .NET Core task, rename it to “Push” and select the “nuget push” command.
Specify the path ($(Build.ArtifactStagingDirectory)/*.nupkg in our case) and select the feed location. The feed that you created at the start of this article should appear in the list.
Select it. Boom, done.
Finally, let’s publish the artifact to our Azure DevOps project at the end of the build. Select the Publish Build Artifacts task. You may leave it as it is, it works just fine with the default settings.
Now we’re done. Save and queue your build definition and see the magic happen.
Consume your private NuGet Feed
Go back to the Packages area in Azure DevOps, select your feed and hit “Connect to feed”. You’ll see some instructions for your feed, but it’s fairly simple to set up.
Just copy your package source URL, go to Visual Studio, open the NuGet Package Manager, go to its settings and add a new source. Choose a fancy name, insert the source URL. Done.
Search for your package in the NuGet Package Manager and it should appear there, ready for installation. Make sure to select the appropriate feed (or just all feeds) from the top right select box.
Next time we’ll give permissions and some minor features a poke.
Have fun using your custom packages!