Publishing NuGet Packages with Azure Artifacts
This articles outlines how to develop and publish NuGet packages.
NuGet Packages #
What are the NuGet packages? First, let's talk about NuGet is package manager for .NET (and .NET Framework). There are essentially three ways to share code in .NET:
- Share the code, that is, the source code. This usually means copying and pasting the code into our application.
- Share the binary. This often easier to maintain than sharing the code, however, it is generally bad practice to keep binaries in source control, especially in Git. Additionally, if it's not well documented (and it often isn't), it's hard to know how to use it.
- NuGet packages. This often is a reference in a project or configuration file where we specify the name of the package and the version we want. When the project is built, it automatically checks the name and version against the public NuGet repository and downloads the binaries. Threfore, we don't need to keep binaries in our source control, and we can clearly document what are our dependencies
At this point, we may wonder, why not share the code in the first place. More often than not, that is an appropriate solution, especially when working on small teams and on small projects. However, there are cases where we want the same behavior or functionality and instead of reinventing the wheel or copying code that can easily become outdated, it's better to use a sharable package. Consider, how many times we would need to write e-mail client in C#? Consider, which functionalities are so complicated, that it's easier to purchase an already built solution. These are cases, where we want NuGet packages.
WARNING: Not everything needs to be a NuGet package. If we know something will be reused at least 3 times, let's make it a NuGet package from the get-go. If there is only a potential need, let's write it as a library project within an application. Once three or more applications need the exact same functionality, we can create a NuGet package. NuGet packages themselves need a level of governance so there is a level of investment that goes into creating a NuGet packages specially as more applications depend on them.
In this article, we are going to cover how to do two things:
- How to create a NuGet packages from a .NET project using the dotnet cli
- How to create NuGet repository with Azure Artifacts or feed to host our packages
Creating NuGet Packages #
First, let's begin with how to create a NuGet package.
Class Library Project #
It all begins with a library project. Library projects are .NET projects that produce binaries, but no executables. These projects are meant to be used by other projects, not be executed. For more information on how to create a class library project see here: Create a .NET class library using Visual Studio - .NET | Microsoft Learn
Configuring NuGet in the project #
Now, that we have created a library project, we can create a NuGet package from our library project. Here's an example of the the .csproj file should look like:
netstandard2.0
0.0.1
README.md
false
For details on additional properties see here: Create a NuGet package with the dotnet CLI | Microsoft Learn
Packing the NuGet Package #
Now, let's create the NuGet package First, we build the project to ensure that our project is buildable.
dotnet build
Next, we pack the package with:
dotnet pack
When we navigate to ./bin/Release we are going to find a file with the .nupkg extension. That's our NuGet package.
Creating a Private NuGet Feed #
Our next step is to publish our NuGet package. But where do we publish it. Well, we have a couple of options:
- We can publish our NuGet package into the public NuGet repository: nuget.org. There's way to make our NuGet package accessible via an API key and therefore making it private. However, if we have Azure DevOps, then:
- We can create a private feed within Azure Artifacts where we can control the organizational scope of access (who within our organization can use this NuGet package)
NOTE: At this point, we can see the value of having a private NuGet feed (or any dependency management feed, e.g. NPM). This enables an organization to share code securely in a scalable and maintainable manner.
Azure Artifacts#
Azure Artifacts is a service within Azure DevOps to privately store dependencies. We are going to use Azure Artifacts to create a NuGet feed. To do this, we can follow these steps: Get started with NuGet packages and Azure Artifacts - Azure Artifacts | Microsoft Learn
Publishing the NuGet Package#
Once our feed is created, we can now publish or push our NuGet package to our private repository. Here's a sample command on how to publish a NuGet package:
dotnet nuget push ./bin/Release/{ProjectName}.{versionnumber}.nupkg --source https://dev.azure.com/org/project/_packaging/TestPrivateFeed/nuget/v3/index.json --api-key dummy --interactive
The main command is dotnet nuget push.
The location of the NuGet package ./bin/Release/{ProjectName}.Lib.{versionnumber}.nupkg
The location of the private repository: --source https://dev.azure.com/org/project/_packaging/TestPrivateFeed/nuget/v3/index.json
The authentication parameters (because not everyone should be allowed to publish NuGet packages): --api-key dummy --interactive
NOTE: The api key "dummy" is used because the user here has been authenticated using Windows Authentication. To push from an unauthenticated user profile, an actual API key is needed.
Full instructions for other cases may be found here: Publish and restore packages with dotnet CLI - Azure Artifacts | Microsoft Learn
Consuming the NuGet Package#
To use our NuGet package we must do two things: we need to tell our project what the NuGet package is and where it is.
By default, all .NET projects look at the nuget.org feed, however, if a project wants to use our NuGet package and other nuget.org packages, it will need the following nuget.config file:
This configuration file tells our project where to look, but not what to look for. Now, we need to add our NuGet package as a package reference in the application's .csproj file.
Now, we are able to build or restore our project successfully.
- Previous: Past Works
- Next: Migrating to HTMX