Create and publish a package using Visual Studio (.NET Standard)

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


  1. Install any edition of Visual Studio 2017 from with any .NET-related workload. Visual Studio 2017 automatically includes NuGet capabilities when a .NET workload is installed.

  2. Install the nuget.exe CLI by downloading it from, saving that .exe file to a suitable folder, and adding that folder to your PATH environment variable.

    Alternately, if you have the .NET Core SDK installed, you can use the dotnet CLI.

  3. Register for a free account on 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.

  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)


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.

Configure package properties

  1. Select the Project > Properties menu command, then select the Package tab. (The Package tab appears only for .NET Standard class library projects; if you are targeting .NET Framework, see Create and publish a .NET Framework package instead.)

    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 description of the different properties, see .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 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.

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

  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 ==========

Alternate option: 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.)

msbuild /t:pack /p:Configuration=Release

The package can then be found in the bin\Release folder.

For additional options with msbuild /t:pack, see NuGet pack and restore as MSBuild targets.

Publish the package

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


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

Packages published to 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 account or create an account if you don't have one already.

  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. Under API Key, 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

  5. Important: 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 via the CLI.

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 Introducing scoped API keys (

Publish with nuget push

This step is an alternative to using dotnet.exe.

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

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

    nuget push AppLogger.1.0.0.nupkg qz2jga8pl3dvn2akksyquwcs9ygggg4exypy3bhxy6w6x6 -Source
  3. nuget.exe displays the results of the publishing process:

    Pushing AppLogger.1.0.0.nupkg to ''...
        Created 6829ms
    Your package was pushed.

See nuget push.

Publish with dotnet nuget push

This step is an alternative to using nuget.exe.

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

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

    dotnet nuget push AppLogger.1.0.0.nupkg -k qz2jga8pl3dvn2akksyquwcs9ygggg4exypy3bhxy6w6x6 -s
  3. dotnet displays the results of the publishing process:

    info : Pushing AppLogger.1.0.0.nupkg to ''...
    info :   PUT
    info :   Created 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, 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 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, 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

  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