NuGet package with Azure DevOps

Today we are going to create our own NuGet package, publish it to Azure DevOps, and then consume it in our application. As our solution grows, it becomes important to break apart some of our dependencies. Sometimes these dependencies are common modules we want to share with other projects, or we may be developing a microservice and need to decouple dependencies from our solution.

For example, I have created a project for Extensions. In this package, there are a lot of extensions for strings, enums, datetime, list and a lot more. This is a quite useful package and I want to use it across my organization.

This adds some flexibility to our upgrade path we could upgrade our models NuGet package, and then consume the new version in the service, but not the website. As we have control over when to upgrade the NuGet package, we have more control over deciding when to upgrade the product.

Creating the Models NuGet package

Our first step is to create a new .NET 5 class library project for our models. We add a new project to the solution, selecting the “Class Library” project template.

Now, in this class, I’m going to add the models, the functions or any other C# code I want to share across my applications. When ready, open Azure DevOps.

Creating the NuGet package feed

Next, in Azure DevOps, we browse to the Azure Artifacts section. As we haven’t setup any feeds yet, there is only the “New Feed” button, which we click.

In the “Create new feed” page, we add a new name for our feed, and leave the options at their current defaults – most projects don’t need to customize these, but in a private situation, you may decide to limit visibility. Fill the form and click on Create.

With the feed created, it’s time to connect – we click the “Connect to feed” button.

Now, you have to choose how you want to connect to the new feed. For example, click on Visual Studio.

So, Azure DevOps gives you all the instructions to connect your Visual Studio to this feed.

Pushing our package to NuGet with DevOps

Now that we have a feed to publish our package into, let us create a new build and release process. First we need to create a new YAML file to build the package.

# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml

trigger:
- main

pool:
  vmImage: ubuntu-latest

steps:
- task: DotNetCoreCLI@2
  displayName: Restore packages
  inputs:
    command: 'restore'
    projects: '**/*.csproj'
    feedsToUse: 'select'
- task: DotNetCoreCLI@2
  displayName: Build project
  inputs:
    command: 'build'
    projects: '**/*.csproj'
- task: DotNetCoreCLI@2
  displayName: Run tests
  inputs:
    command: 'test'
    projects: '**/*[Te]ests/*.csproj'
- task: NuGetCommand@2
  diplayName: Prepare the package
  inputs:
    command: 'pack'
    packagesToPack: '**/*.csproj'
    versioningScheme: 'off'
- task: NuGetCommand@2
  displayName: Push the package
  inputs:
    command: 'push'
    packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg'
    nuGetFeedType: 'internal'
    publishVstsFeed: 'your-feed'

Packages are immutable, which means they can’t be updated or replaced. Therefore versions need to be unique and sequential. There are a number of strategies for managing versioning in packages, we are trying to automate as much as possible.

One strategy is to manually update major and minor versions to represent bigger changes, and then append the “build.buildid” variable to automatically increment the version and ensure a unique version of our models is pushed to our NuGet feed. Each build increments the “build.buildid” variable.

So, in the YAML file I’m going to restore the packages, build the projects, run the tests and then publish the NuGet package.

To reference a YAML file we’ve already created, we browse to Azure Pipelines and create a new build, selecting the “Use the visual designer” option.

Then, select the repository from where you want to read your project.

If the azure-pipelines.yml is in the root of your repository, Azure DevOps shows you the file. If you are ok, you can Run the pipeline.

Lacks permission to complete this action. You need to have ‘ReadPackages’

This is a common problem when you are creating NuGet package with Azure DevOps. Although the pipeline and the NuGet is in Azure DevOps, the pipeline doesn’t have permission to push anything. For this reason, we have to allow the pipeline to work. So, go to the Artifacts page.

Then, click on the gear on the top-right corner for Feed settings. Here, add the user Project Collection Valid Users, searching in the drawer. Then, Save. Although the requirement is that this use has the privilege of Reader, we have to select Contributor because instead it won’t be able to push the new package.

Configure Visual Studio

With the feed setup and our package successfully published, it’s time to connect to the feed and start consuming our NuGet packages in Visual Studio. On the Tools menu, select Options > NuGet Package Manager > Package Sources. Select the green plus in the upper-right corner.

So, this new package source is filled with default values, we need to configure it.

Now, copy from the section Connect to feed in the Artifacts the source and click on Update.

So, I can find the my packages from Visual Studio. For example, open Manage Packages for Solution and select the Package source you created.

Finally, you can have the list of all your NuGet package with Azure DevOps!