NuGet Packaging Series

This article is part of the Creating NuGet Packages series. You can find the complete list of articles in the series at the end.

Many Roads to Publish

Depending on your needs, you have a few options for publishing your NuGet package and making it accessible to a wide audience. Let's divide those needs into publicly available packages and private ones.

Public Packages

NuGet.org

If you are working on an open-source project and want to share it with the world, Nuget.org is a no-brainer. It is the most popular and widely used platform for publishing NuGet packages. It is also the official and public NuGet package repository maintained by Microsoft.

To publish your package on NuGet.org, you must create an account and follow their guidelines for package submission. Once your package is approved, it will be available for others to download and use.

Setting Up:

• If you don't have a NuGet.org account, create one.

• If you don't have NuGet CLI, download it from here. The minimum version must be 4.1.0

• Once logged in, go to the API keys section and create a new API key.

• Use the following command to push your package to NuGet.org:

 dotnet nuget push "PATH_TO_YOUR_NUPKG_FILE" -k YOUR_API_KEY -s https://api.nuget.org/v3/index.json

• Where:

  • PATH_TO_YOUR_NUPKG_FILE is the path to your .nupkg file.

  • YOUR_API_KEY is your actual API key for NuGet.org

Private Package Feeds

You can set up a private package feed if you prefer to keep your package private or limit its availability to a specific group of users. This can be useful if you are developing internal libraries for your organization or if you want to distribute your package to a select group of clients.

There are several options for hosting private package feeds, such as:

Local or Shared Drive

This approach is really simple. After the package is built, copy it to a certain directory on your disk or shared disc in your organization. Even OneDrive, Dropbox, and similar work for this kind of simplistic distribution.

Setting Up:

There's no need for an advanced setup. Build the packages using a .bat or .sh script and copy the artifacts into the desired directory.

GitHub Packages

If your project is hosted on GitHub, you can leverage GitHub Packages to publish your NuGet package. GitHub Packages allows you to host your packages within the same repository as your source code, making it convenient for developers who are already using GitHub for version control.

Setting Up:

To publish your package on GitHub Packages, you need to enable the feature in your repository settings and follow their guidelines for package publishing. Once published, your package will be available for installation directly from GitHub. Full documentation is here.

The easiest way is to use the dotnet nuget push command as we did for pushing to NuGet.org. The difference is that only the source path points to your GitHub Packages URL.

GitHub Personal Access Token

Before anything, you must create your GitHub personal access token (PAT). Log in to your GitHub account and go to Settings / Developer Settings / Personal Access Tokens / Tokens (classic).

Once there, generate a new PAT (Classic) and set permissions to:

• write:packages

• read:packages

• delete:packages

It should look like this:

Create a token and store its value somewhere safe. After this, you are ready for package publishing.

Pushing the NuGet package to your private GitHub packages

Pushing the package to GitHub NuGet packages is almost identical to pushing it to NuGet.org. The only distinction lies in the URL.

dotnet nuget push "PATH_TO_YOUR_NUPKG_FILE" -k PAT -s https://nuget.pkg.github.com/OWNER/index.json

• Where:

  • PATH_TO_YOUR_NUPKG_FILE is the path to your .nupkg file.

  • PAT is your Personal Access Token (PAT) you generated on GitHub for the GitHub Packages

  • OWNER is your GitHub username or organization name under which the repository resides

By default, the packages are set to private access. For information on adjusting access settings, refer to the official documentation.

After executing this command, your package should be successfully pushed to your private GitHub package repo. In my case, this looks like this:

Other

There are also other ones, like Azure Artifacts on Azure DevOps, MyGet, or ProGet. The setup is pretty much similar to GitHub.

Consume Your Package

After publishing, anyone can add your package to the projects using the package manager in IDE-s such as Visual Studio or JetBrains Rider from the .NET CLI or manually add it to their *.csproj file.

VSCode, unfortunately, only supports the .NET CLI approach for now.

In the "Multiple & Custom Nuget Registries" article, we will explore the step-by-step process of configuring your preferred IDE to access NuGet packages from multiple sources easily. These sources include NuGet.org, your local disk, and a private GitHub repository.

What Have We Learned?

Publishing your NuGet package is important in making your libraries accessible to a wider audience. Whether you choose NuGet.org, private package feeds, or GitHub Packages, each option has advantages and considerations. Evaluate your requirements and choose the platform that best suits your needs.

In this article, we learned:

• How to publish your packages to the official NuGet.org

• How to publish to local or shared disks

• How to publish to private GitHub NuGet repo

Example Project on GitHub

An example project for this article can be found here:

Workshop-Nuget-Packaging

Creating NuGet Packages Series

This article is part of the Creating NuGet Packages series. If you enjoyed this one and want more, here is the complete list in the series:

• My NuGet First Package

• Bundling Multiple Projects with .nuspec

• Packages with Source Generators

• Tool Packages

• Publishing Your Packages

• Multiple & Custom Nuget Registries

Happy Coding!