When you create a NuGet package from your code, you package that functionality into a component that can be shared with and used by any number of other developers. This article describes how to create a package using MSBuild. MSBuild comes preinstalled with every Visual Studio workload that contains NuGet. Additionally you can also use MSBuild through the dotnet CLI withdotnet msbuild.

For .NET Core and .NET Standard projects that use theSDK-style format, and any other SDK-style projects, NuGet uses information in the project file directly to create a package. For a non-SDK-style project that uses<PackageReference>, NuGet also uses the project file to create a package.

SDK-style projects have the pack functionality available by default.For non-SDK-style PackageReference projects, it is also available by default starting from Visual Studio 2026.In earlier versions of Visual Studio you need to add the NuGet.Build.Tasks.Pack package to the project dependencies and we recommend removing this package reference when upgrading to Visual Studio 2026.For detailed information about MSBuild pack targets, seeNuGet pack and restore as MSBuild targets.

For SDK-style projects,msbuild -t:pack is functionally equivalent todotnet pack.

Set properties

The following properties are required to create a package.

• PackageId, the package identifier, which must be unique across the gallery that hosts the package. If not specified, the default value isAssemblyName.
• Version, a specific version number in the formMajor.Minor.Patch[-Suffix] where-Suffix identifiespre-release versions. If not specified, the default value is 1.0.0.
• The package title as it should appear on the host (like nuget.org)
• Authors, author and owner information. If not specified, the default value isAssemblyName.
• Company, your company name. If not specified, the default value isAssemblyName.

Additionally if you are packing non-SDK-style projects that use PackageReference, the following is required:

• PackageOutputPath, the output folder for the package generated when calling pack.

In Visual Studio, you can set these values in the project properties (right-click the project in Solution Explorer, chooseProperties, and select thePackage tab). You can also set these properties directly in the project files (.csproj).

<PropertyGroup>  <PackageId>ClassLibDotNetStandard</PackageId>  <Version>1.0.0</Version>  <Authors>your_name</Authors>  <Company>your_company</Company></PropertyGroup>

The following example shows a simple, complete project file with these properties included.

<Project Sdk="Microsoft.NET.Sdk">  <PropertyGroup>    <TargetFramework>netstandard2.0</TargetFramework>    <PackageId>ClassLibDotNetStandard</PackageId>    <Version>1.0.0</Version>    <Authors>your_name</Authors>    <Company>your_company</Company>  </PropertyGroup></Project>

You can also set the optional properties, such asTitle,PackageDescription, andPackageTags, as described inMSBuild pack targets,Controlling dependency assets, andNuGet metadata properties.

For details on declaring dependencies and specifying version numbers, seePackage references in project files andPackage versioning. It is also possible to surface assets from dependencies directly in the package by using the<IncludeAssets> and<ExcludeAssets> attributes. For more information, seeeControlling dependency assets.

Add an optional description field

The package's optional description appears on theREADME tab of the package's nuget.org page. The description pulls from the<Description> in the project file or the$description in the.nuspec file.

The following example shows aDescription in the.csproj file for a .NET package:

<Project Sdk="Microsoft.NET.Sdk">  <PropertyGroup>    <PackageId>Azure.Storage.Blobs</PackageId>    <Version>12.4.0</Version>    <PackageTags>Microsoft Azure Storage Blobs;Microsoft;Azure;Blobs;Blob;Storage;StorageScalable</PackageTags>    <Description>      This client library enables working with the Microsoft Azure Storage Blob service for storing binary and text data.      For this release see notes - https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Azure.Storage.Blobs/README.md and https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Azure.Storage.Blobs/CHANGELOG.md      in addition to the breaking changes https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Azure.Storage.Blobs/BreakingChanges.txt      Microsoft Azure Storage quickstarts and tutorials - https://learn.microsoft.com/azure/storage/      Microsoft Azure Storage REST API Reference - https://learn.microsoft.com/rest/api/storageservices/      REST API Reference for Blob Service - https://learn.microsoft.com/rest/api/storageservices/blob-service-rest-api    </Description>  </PropertyGroup></Project>

Choose a unique package identifier and set the version number

The package identifier and the version number uniquely identify the exact code that's contained in the package.

Follow these best practices to create the package identifier:

• The identifier must beunique across nuget.org and all other locations that host the package. To avoid conflicts, a good pattern is to use your company name as the first part of the identifier.

• Follow a.NET namespace-like naming convention, using dot notation. For example, useContoso.Utility.UsefulStuff rather thanContoso-Utility-UsefulStuff orContoso_Utility_UsefulStuff. It's also helpful for consumers if you match the package identifier to the namespace the code uses.

• If you produce a package ofsample code that demonstrates how to use another package, append.Sample to the identifier, as inContoso.Utility.UsefulStuff.Sample.

  The sample package has a dependency on the original package. When you create the sample package, add<IncludeAssets> with thecontentFiles value. In thecontent folder, arrange the sample code in a folder called\Samples\<identifier>, such as\Samples\Contoso.Utility.UsefulStuff.Sample.

Follow these best practices to set the package version:

• In general, set the package version tomatch the project or assembly version, although this isn't strictly required. Matching the version is simple when you limit a package to a single assembly. NuGet itself deals with package versions when resolving dependencies, not assembly versions.

• If you use a non-standard version scheme, be sure to consider theNuGet versioning rules as explained inPackage versioning. NuGet is mostlySemantic Versioning 2.0.0-compliant.

Configure project for pack

SDK-style projects do not require any additional configuration.

Non-SDK-style projects either need at least one package installed (via PackageReference, not packages.config), or the project explicitly needs to instruct NuGet to treat the project as a PackageReference project via theRestoreProjectStyle property.

Visual Studio 2022 and earlier does not have pack built-in, so you also need to install the NuGet.Build.Tasks.Pack package.When upgrading to Visual Studio 2026 or later, we recommend uninstalling the package, so that you benefit from new features and bug fixes.

1. Edit the project file.

   If you want to explicitly instruct NuGet to treat the project as PackageReference (the project does not have any packages installed), find or add a<PropertyGroup> that does not have anyCondition statement, and add:

   <PropertyGroup>  <!-- other properties -->  <RestoreProjectStyle>PackageReference</RestoreProjectStyle>  <!-- more properties are allowed --></PropertyGroup>

   If you are using Visual Studio 2022 or earlier, add the following after the<PropertyGroup> element:

   <ItemGroup>  <!-- ... -->  <PackageReference Include="NuGet.Build.Tasks.Pack" Version="6.14.0" PrivateAssets="all" />  <!-- ... --></ItemGroup>

   Note

   Consider using the latest version of this package available.

2. Open a Developer command prompt (In theSearch box, typeDeveloper command prompt).

   You typically want to start the Developer Command Prompt for Visual Studio from theStart menu, as it will be configured with all the necessary paths for MSBuild.

3. Switch to the folder containing the project file and type the following command to restore the NuGet.Build.Tasks.Pack package.

   # Uses the project file in the current folder by defaultmsbuild -t:restore

   Make sure that the MSBuild output indicates that the build completed successfully.

Run the msbuild -t:pack command

To build a NuGet package (a.nupkg file) from the project, run themsbuild -t:pack command, which also builds the project automatically:

In the Developer command prompt for Visual Studio, type the following command:

# Uses the project file in the current folder by defaultmsbuild -t:pack

The output shows the path to the.nupkg file.

Microsoft (R) Build Engine version 16.1.76+g14b0a930a7 for .NET FrameworkCopyright (C) Microsoft Corporation. All rights reserved.Build started 8/5/2019 3:09:15 PM.Project "C:\Users\username\source\repos\ClassLib_DotNetStandard\ClassLib_DotNetStandard.csproj" on node 1 (pack target(s)).GenerateTargetFrameworkMonikerAttribute:Skipping target "GenerateTargetFrameworkMonikerAttribute" because all output files are up-to-date with respect to the input files.CoreCompile:  ...CopyFilesToOutputDirectory:  Copying file from "C:\Users\username\source\repos\ClassLib_DotNetStandard\obj\Debug\netstandard2.0\ClassLib_DotNetStandard.dll" to "C:\Use  rs\username\source\repos\ClassLib_DotNetStandard\bin\Debug\netstandard2.0\ClassLib_DotNetStandard.dll".  ClassLib_DotNetStandard -> C:\Users\username\source\repos\ClassLib_DotNetStandard\bin\Debug\netstandard2.0\ClassLib_DotNetStandard.dll  Copying file from "C:\Users\username\source\repos\ClassLib_DotNetStandard\obj\Debug\netstandard2.0\ClassLib_DotNetStandard.pdb" to "C:\Use  rs\username\source\repos\ClassLib_DotNetStandard\bin\Debug\netstandard2.0\ClassLib_DotNetStandard.pdb".GenerateNuspec:  Successfully created package 'C:\Users\username\source\repos\ClassLib_DotNetStandard\bin\Debug\AppLogger.1.0.0.nupkg'.Done Building Project "C:\Users\username\source\repos\ClassLib_DotNetStandard\ClassLib_DotNetStandard.csproj" (pack target(s)).Build succeeded.    0 Warning(s)    0 Error(s)Time Elapsed 00:00:01.21

Automatically generate package on build

To automatically runmsbuild -t:pack when you build or restore the project, add the following line to your project file within<PropertyGroup>:

<GeneratePackageOnBuild>true</GeneratePackageOnBuild>

When you runmsbuild -t:pack on a solution, this packs all the projects in the solution that are packable (<IsPackable> property is set totrue).

Test package installation

Before publishing a package, you typically want to test the process of installing a package into a project. The tests make sure that the necessarily files all end up in their correct places in the project.

You can test installations manually in Visual Studio or on the command line using the normalpackage installation steps.

Next Steps

Once you've created a package, which is a.nupkg file, you can publish it to the gallery of your choice as described onPublishing a Package.

You might also want to extend the capabilities of your package or otherwise support other scenarios as described in the following topics:

• NuGet pack and restore as MSBuild targets
• Package versioning
• Support multiple target frameworks
• Transformations of source and configuration files
• Localization
• Pre-release versions
• Set package type
• MSBuild props and targets
• Create packages with COM interop assemblies

Finally, there are additional package types to be aware of:

• Native Packages
• Symbol Packages