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

Creating a NuGet package from a .NET Framework Class Library involves creating the DLL in Visual Studio on Windows, then using the nuget.exe command line tool to create and publish the package.

Note

This Quickstart applies to Visual Studio 2017 for Windows only. Visual Studio for Mac does not include the capabilities described here. Use the dotnet CLI tools instead.

Prerequisites

  1. Install any edition of Visual Studio 2017 from visualstudio.com 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 nuget.org, saving that .exe file to a suitable folder, and adding that folder to your PATH environment variable.

  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 Framework 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, select the Visual C# node, select the "Class Library (.NET Framework)" 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. You can also set the target frameworks however you like. For example, see the guides for UWP and Xamarin.

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:

using System;

namespace AppLogger
{
    public class Logger
    {
        public void Log(string text)
        {
            Console.WriteLine(text);
        }
    }
}

Tip

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. See Create and publish a package using Visual Studio (.NET Standard).

Configure project properties for the package

A NuGet package contains a manifest (a .nuspec file), that contains relevant metadata such as the package identifier, version number, description, and more. Some of these can be drawn from the project properties directly, which avoids having to separately update them in both the project and the manifest. This section describes where to set the applicable properties.

  1. Select the Project > Properties menu command, then select the Application tab.

  2. In the Assembly name field, give your package a unique identifier.

    Important

    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. Select the Assembly Information... button, which brings up a dialog box in which you can enter other properties that carry into the manifest (see .nuspec file reference - replacement tokens). The most commonly used fields are Title, Description, Company, Copyright, and Assembly version. These properties ultimately appear with your package on a host like nuget.org, so make sure they're fully descriptive.

    Assembly information in a .NET Framework project in Visual Studio

  4. Optional: to see and edit the properties directly, open the Properties/AssemblyInfo.cs file in the project.

  5. When the properties are set, set the project configuration to Release and rebuild the project to generate the updated DLL.

Generate the initial manifest

With a DLL in hand and project properties set, you now use the nuget spec command to generate an initial .nuspec file from the project. This step includes the relevant replacement tokens to draw information from the project file.

You run nuget spec only once to generate the initial manifest. When updating the package, you either change values in your project or edit the manifest directly.

  1. Open a command prompt and navigate to the project folder containing AppLogger.csproj file.

  2. Run the following command: nuget spec AppLogger.csproj. By specifying a project, NuGet creates a manifest that matches the name of the project, in this case AppLogger.nuspec. It also include replacement tokens in the manifest.

  3. Open AppLogger.nuspec in a text editor to examine its contents, which should appear as follows:

    <?xml version="1.0"?>
    <package >
      <metadata>
        <id>$id$</id>
        <version>$version$</version>
        <title>$title$</title>
        <authors>$author$</authors>
        <owners>$author$</owners>
        <licenseUrl>http://LICENSE_URL_HERE_OR_DELETE_THIS_LINE</licenseUrl>
        <projectUrl>http://PROJECT_URL_HERE_OR_DELETE_THIS_LINE</projectUrl>
        <iconUrl>http://ICON_URL_HERE_OR_DELETE_THIS_LINE</iconUrl>
        <requireLicenseAcceptance>false</requireLicenseAcceptance>
        <description>$description$</description>
        <releaseNotes>Summary of changes made in this release of the package.</releaseNotes>
        <copyright>Copyright 2018</copyright>
        <tags>Tag1 Tag2</tags>
      </metadata>
    </package>
    

Edit the manifest

  1. NuGet produces an error if you try to create a package with default values in your .nuspec file, so you must edit the following fields before proceeding. See .nuspec file reference - optional metadata elements for a description of how these are used.

    • licenseUrl
    • projectUrl
    • iconUrl
    • releaseNotes
    • tags
  2. For packages built for public consumption, pay special attention to the Tags property, as tags help others find your package on sources like nuget.org and understand what it does.

  3. You can also add any other elements to the manifest at this time, as described on .nuspec file reference.

  4. Save the file before proceeding.

Run the pack command

  1. From a command prompt in the folder containing your .nuspec file, run the command nuget pack.

  2. NuGet generates a .nupkg file in the form of identifier-version.nupkg, which you'll find in the current folder.

Publish the package

Once you have a .nupkg file, you publish it to nuget.org using nuget.exe with an API key acquired from nuget.org. For nuget.org you must use nuget.exe 4.1.0 or higher.

Note

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.

  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 (blogs.nuget.org).

Publish with nuget push

  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 https://api.nuget.org/v3/index.json
    
  3. nuget.exe displays the results of the publishing process:

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

See 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