Quickstart: Create and publish a NuGet package using Visual Studio (.NET Standard, Windows only)

It's a simple process to create a NuGet package from a .NET Standard Class Library in Visual Studio on Windows, and then publish it to nuget.org using a CLI tool.


If you are using Visual Studio for Mac, refer to this information on creating a NuGet package, or use the dotnet CLI tools.


  1. Install any edition of Visual Studio 2019 from visualstudio.com with a .NET Core related workload.

  2. If it's not already installed, install the dotnet CLI.

    For the dotnet CLI, starting in Visual Studio 2017, the dotnet CLI is automatically installed with any .NET Core related workloads. Otherwise, install the .NET Core SDK to get the dotnet CLI. The dotnet CLI is required for .NET Standard projects that use the SDK-style format (SDK attribute). The default .NET Standard class library template in Visual Studio 2017 and higher, which is used in this article, uses the SDK attribute.


    If you are working with a non-SDK-style project, follow the procedures in Create and publish a .NET Framework package (Visual Studio) to create and publish the package instead. For this article, the dotnet CLI is recommended. Although you can publish any NuGet package using the nuget.exe CLI, some of the steps in this article are specific to SDK-style projects and the dotnet CLI. The nuget.exe CLI is used for non-SDK-style projects (typically .NET Framework).

  3. Register for a free account on nuget.org if you don't have one already. Creating a new account sends a confirmation email. You must confirm the account before you can upload a package.

Create a class library project

You can use an existing .NET Standard Class Library project for the code you want to package, or create a simple one as follows:

  1. In Visual Studio, choose File > New > Project, expand the Visual C# > .NET Standard node, select the "Class Library (.NET Standard)" template, name the project AppLogger, and click OK.


    Unless you have a reason to choose otherwise, .NET Standard is the preferred target for NuGet packages, as it provides compatibility with the widest range of consuming projects.

  2. Right-click on the resulting project file and select Build to make sure the project was created properly. The DLL is found within the Debug folder (or Release if you build that configuration instead).

Within a real NuGet package, of course, you implement many useful features with which others can build applications. For this walkthrough, however, you won't write any additional code because a class library from the template is sufficient to create a package. Still, if you'd like some functional code for the package, use the following:

namespace AppLogger
    public class Logger
        public void Log(string text)

Configure package properties

  1. Right-click the project in Solution Explorer, and choose Properties menu command, then select the Package tab.

    The Package tab appears only for SDK-style projects in Visual Studio, typically .NET Standard or .NET Core class library projects; if you are targeting a non-SDK style project (typically .NET Framework), either migrate the project or see Create and publish a .NET Framework package instead for step-by-step instructions.

    NuGet package properties in a Visual Studio project


    For packages built for public consumption, pay special attention to the Tags property, as tags help others find your package and understand what it does.

  2. Give your package a unique identifier and fill out any other desired properties. For a mapping of MSBuild properties (SDK-style project) to properties in a .nuspec, see pack targets. For descriptions of properties, see the .nuspec file reference. All of the properties here go into the .nuspec manifest that Visual Studio creates for the project.


    You must give the package an identifier that's unique across nuget.org or whatever host you're using. For this walkthrough we recommend including "Sample" or "Test" in the name as the later publishing step does make the package publicly visible (though it's unlikely anyone will actually use it).

    If you attempt to publish a package with a name that already exists, you see an error.

  3. (Optional) To see the properties directly in the project file, right-click the project in Solution Explorer and select Edit AppLogger.csproj.

    This option is only available starting in Visual Studio 2017 for projects that use the SDK-style attribute. Otherwise, right-click the project and choose Unload Project. Then right-click the unloaded project and choose Edit AppLogger.csproj.

Run the pack command

  1. Set the configuration to Release.

  2. Right click the project in Solution Explorer and select the Pack command:

    NuGet pack command on the Visual Studio project context menu

    If you don't see the Pack command, your project is probably not an SDK-style project and you need to use the nuget.exe CLI. Either migrate the project and use dotnet CLI, or see Create and publish a .NET Framework package instead for step-by-step instructions.

  3. Visual Studio builds the project and creates the .nupkg file. Examine the Output window for details (similar to the following), which contains the path to the package file. Note also that the built assembly is in bin\Release\netstandard2.0 as befits the .NET Standard 2.0 target.

    1>------ Build started: Project: AppLogger, Configuration: Release Any CPU ------
    1>AppLogger -> d:\proj\AppLogger\AppLogger\bin\Release\netstandard2.0\AppLogger.dll
    1>Successfully created package 'd:\proj\AppLogger\AppLogger\bin\Release\AppLogger.1.0.0.nupkg'.
    ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

(Optional) Generate package on build

You can configure Visual Studio to automatically generate the NuGet package when you build the project.

  1. In Solution Explorer, right-click the project and choose Properties.

  2. In the Package tab, select Generate NuGet package on build.

    Automatically generate package on build


When you automatically generate the package, the time to pack increases the build time for your project.

(Optional) pack with MSBuild

As an alternate to using the Pack menu command, NuGet 4.x+ and MSBuild 15.1+ supports a pack target when the project contains the necessary package data. Open a command prompt, navigate to your project folder and run the following command. (You typically want to start the "Developer Command Prompt for Visual Studio" from the Start menu, as it will be configured with all the necessary paths for MSBuild.)

For more information, see Create a package using MSBuild.

Publish the package

Once you have a .nupkg file, you publish it to nuget.org using either the nuget.exe CLI or the dotnet.exe CLI along with an API key acquired from nuget.org.


Virus scanning: All packages uploaded to nuget.org are scanned for viruses and rejected if any viruses are found. All packages listed on nuget.org are also scanned periodically.

Packages published to nuget.org are also publicly visible to other developers unless you unlist them. To host packages privately, see Hosting packages.

Acquire your API key

  1. Sign into your nuget.org account or create an account if you don't have one already.

    For more information on creating your account, see Individual accounts.

  2. Select your user name (on the upper right), then select API Keys.

  3. Select Create, provide a name for your key, select Select Scopes > Push. Enter * for Glob pattern, then select Create. (See below for more about scopes.)

  4. Once the key is created, select Copy to retrieve the access key you need in the CLI:

    Copying the API key to the clipboard


Always keep your API key a secret! Treat your API key as a password that allows anyone to manage packages on your behalf. You should delete or regenerate your API key if it is accidentally revealed.


Save your key in a secure location because you cannot copy the key again later on. If you return to the API key page, you need to regenerate the key to copy it. You can also remove the API key if you no longer want to push packages.

Scoping allows you to create separate API keys for different purposes. Each key has its expiration timeframe and can be scoped to specific packages (or glob patterns). Each key is also scoped to specific operations: push of new packages and updates, push of updates only, or delisting. Through scoping, you can create API keys for different people who manage packages for your organization such that they have only the permissions they need. For more information, see scoped API keys.

Publish with the dotnet CLI or nuget.exe CLI

Select the tab for your CLI tool, either .NET Core CLI (dotnet CLI) or NuGet (nuget.exe CLI).

This step is the recommended alternative to using nuget.exe.

Before you can publish the package, you must first open a command line.

  1. Change to the folder containing the .nupkg file.

  2. Run the following command, specifying your package name (unique package ID) and replacing the key value with your API key:

    dotnet nuget push AppLogger.1.0.0.nupkg --api-key qz2jga8pl3dvn2akksyquwcs9ygggg4exypy3bhxy6w6x6 --source https://api.nuget.org/v3/index.json
  3. dotnet displays the results of the publishing process:

    info : Pushing AppLogger.1.0.0.nupkg to 'https://www.nuget.org/api/v2/package'...
    info :   PUT https://www.nuget.org/api/v2/package/
    info :   Created https://www.nuget.org/api/v2/package/ 12620ms
    info : Your package was pushed.

See dotnet nuget push.

Publish errors

Errors from the push command typically indicate the problem. For example, you may have forgotten to update the version number in your project and are therefore trying to publish a package that already exists.

You also see errors when trying to publish a package using an identifier that already exists on the host. The name "AppLogger", for example, already exists. In such a case, the push command gives the following error:

Response status code does not indicate success: 403 (The specified API key is invalid,
has expired, or does not have permission to access the specified package.).

If you're using a valid API key that you just created, then this message indicates a naming conflict, which isn't entirely clear from the "permission" part of the error. Change the package identifier, rebuild the project, recreate the .nupkg file, and retry the push command.

Manage the published package

From your profile on nuget.org, select Manage Packages to see the one you just published. You also receive a confirmation email. Note that it might take a while for your package to be indexed and appear in search results where others can find it. During that time your package page shows the message below:

This package has not been indexed yet. It will appear in search results and will be available for install/restore after indexing is complete.

And that's it! You've just published your first NuGet package to nuget.org that other developers can use in their own projects.

If in this walkthrough you created a package that isn't actually useful (such as a package created with an empty class library), you should unlist the package to hide it from search results:

  1. On nuget.org, select your user name (upper right of the page), then select Manage Packages.

  2. Locate the package you want to unlist under Published and select the trash can icon on the right:

    Trash can icon shown for a package listing on nuget.org

  3. On the subsequent page, clear the box labeled List (package-name) in search results and select Save:

    Clearing the List checkbox for a package on nuget.org

Adding a readme and other files

To directly specify files to include in the package, edit the project file and use the content property:

  <Content Include="readme.txt">

This will include a file named readme.txt in the package root. Visual Studio displays the contents of that file as plain text immediately after installing the package directly. (Readme files are not displayed for packages installed as dependencies). For example, here's how the readme for the HtmlAgilityPack package appears:

The display of a readme file for a NuGet package upon installation


Merely adding the readme.txt at the project root will not result in it being included in the resulting package.

Find more NuGet videos on Channel 9 and YouTube.