Package creation workflow

Creating a package starts with the compiled code (typically .NET assemblies) that you want to package and share with others, either through the public gallery or a private gallery within your organization. The package can also include additional files such as a readme that is displayed when the package is installed, and can include transformations to certain project files.

A package can also serve to only pull in any number of other dependencies, without containing any code of its own. Such a package is a convenient way to deliver an SDK that's composed of multiple independent packages. In other cases, a package may contain only symbol (.pdb) files to aid debugging.


When you create a package for use by other developers, it's important to understand that they are taking a dependency on your work. As such, creating and publishing a package also implies a commitment to fixing bugs and making other updates, or at the very least making the package available as open source so others can help to maintain it.

Whatever the case, creating a package begins with deciding which assemblies and other files to package. You then create a manifest file, referred to as a .nuspec file, to describe the package's contents along with its identifer, version number, copyright information, MSBuild props and targets, and much more.

When you've prepared all the necessary files in the appropriate folders and have created the appropriate .nuspec file, you then use the nuget pack command (or theMSBuild pack target) to put everything together into a .nupkg file. You're then ready to deploy the package to whatever host makes it available to other developers.


A NuGet package with the .nupkg extension is simple a ZIP file. To easily examine any package's contents, change the extension to .zip and expand its contents as usual. Just be sure to change the extension back to .nupkg before attempting to upload it to a host.

To learn and understand the creation process, start with Creating a package which guides you through the core processes common to all packages.

From there, you can consider a number of other options for your package:

  • Supporting Multiple Target Frameworks describes how to create a package with multiple variants for different .NET Frameworks.
  • Creating Localized Packages describes how to structure a package with multiple language resources and how to use separate localized satellite packages.
  • Pre-release Packages demonstrates how to release alpha, beta, and rc packages to those customers who are interested.
  • Source and Config File Transformations describes how you can do both one-way token replacements in files that are added to a project, and modify web.config and app.config with settings that are also backed out when the package is uninstalled.
  • Symbol Packages offers guidance for supplying symbols for your library that allow consumers to step into your code while debugging.
  • Package versioning discusses how to identify the exact versions that you allow for your dependencies (other packages that you consume from your package).
  • Native Packages describes the process for creating a package for C++ consumers.

When you're then ready to publish a package to, follow the simple process in Publish a package.

If you want to use a private feed instead of, see the Hosting Packages Overview