title | description | ms.date |
---|---|---|
dotnet pack command |
The dotnet pack command creates NuGet packages for your .NET project. |
11/27/2023 |
This article applies to: ✔️ .NET Core 3.1 SDK and later versions
dotnet pack
- Packs the code into a NuGet package.
dotnet pack [<PROJECT>|<SOLUTION>] [-c|--configuration <CONFIGURATION>]
[--force] [--include-source] [--include-symbols] [--interactive]
[--no-build] [--no-dependencies] [--no-restore] [--nologo]
[-o|--output <OUTPUT_DIRECTORY>] [--runtime <RUNTIME_IDENTIFIER>]
[-s|--serviceable] [--tl:[auto|on|off]] [-v|--verbosity <LEVEL>]
[--version-suffix <VERSION_SUFFIX>]
dotnet pack -h|--help
The dotnet pack
command builds the project and creates NuGet packages. The result of this command is a NuGet package (that is, a .nupkg file).
If you want to generate a package that contains the debug symbols, you have two options available:
--include-symbols
- it creates the symbols package.--include-source
- it creates the symbols package with asrc
folder inside containing the source files.
NuGet dependencies of the packed project are added to the .nuspec file, so they're properly resolved when the package is installed. If the packed project has references to other projects, the other projects aren't included in the package. Currently, you must have a package per project if you have project-to-project dependencies.
By default, dotnet pack
builds the project first. If you wish to avoid this behavior, pass the --no-build
option. This option is often useful in Continuous Integration (CI) build scenarios where you know the code was previously built.
Note
In some cases, the implicit build cannot be performed. This can occur when GeneratePackageOnBuild
is set, to avoid a cyclic dependency between build and pack targets. The build can also fail if there is a locked file or other issue.
You can provide MSBuild properties to the dotnet pack
command for the packing process. For more information, see NuGet pack target properties and the MSBuild Command-Line Reference. The Examples section shows how to use the MSBuild -p
switch for a couple of different scenarios.
Note
Web projects aren't packable.
[!INCLUDEdotnet restore note + options]
[!INCLUDE cli-advertising-manifests]
PROJECT | SOLUTION
The project or solution to pack. It's either a path to a csproj, vbproj, or fsproj file, or to a solution file or directory. If not specified, the command searches the current directory for a project or solution file.
[!INCLUDE configuration]
-
--force
Forces all dependencies to be resolved even if the last restore was successful. Specifying this flag is the same as deleting the project.assets.json file.
[!INCLUDE help]
-
--include-source
Includes the debug symbols NuGet packages in addition to the regular NuGet packages in the output directory. The sources files are included in the
src
folder within the symbols package. -
--include-symbols
Includes the debug symbols NuGet packages in addition to the regular NuGet packages in the output directory.
[!INCLUDE interactive]
-
--no-build
Doesn't build the project before packing. It also implicitly sets the
--no-restore
flag. -
--no-dependencies
Ignores project-to-project references and only restores the root project.
-
--no-restore
Doesn't execute an implicit restore when running the command.
-
--nologo
Doesn't display the startup banner or the copyright message.
-
-o|--output <OUTPUT_DIRECTORY>
Places the built packages in the directory specified.
-
.NET 7.0.200 SDK
In the 7.0.200 SDK, if you specify the
--output
option when running this command on a solution, the CLI will emit an error. This is a regression and was fixed in 7.0.201 and later versions of the .NET SDK.
-
-
--runtime <RUNTIME_IDENTIFIER>
Specifies the target runtime to restore packages for. For a list of Runtime Identifiers (RIDs), see the RID catalog.
-
-s|--serviceable
Sets the serviceable flag in the package. For more information, see .NET Blog: .NET Framework 4.5.1 Supports Microsoft Security Updates for .NET NuGet Libraries.
[!INCLUDE tl]
[!INCLUDE verbosity]
-
--version-suffix <VERSION_SUFFIX>
Defines the value for the
VersionSuffix
MSBuild property. The effect of this property on the package version depends on the values of theVersion
andVersionPrefix
properties, as shown in the following table:Properties with values Package version None 1.0.0
Version
$(Version)
VersionPrefix
only$(VersionPrefix)
VersionSuffix
only1.0.0-$(VersionSuffix)
VersionPrefix
andVersionSuffix
$(VersionPrefix)-$(VersionSuffix)
If you want to use
--version-suffix
, specifyVersionPrefix
and notVersion
in the project file. For example, ifVersionPrefix
is0.1.2
and you pass--version-suffix rc.1
todotnet pack
, the package version will be0.1.2-rc.1
.If
Version
has a value and you pass--version-suffix
todotnet pack
, the value specified for--version-suffix
is ignored.
-
Pack the project in the current directory:
dotnet pack
-
Pack the
app1
project:dotnet pack ~/projects/app1/project.csproj
-
Pack the project in the current directory and place the resulting packages into the
nupkgs
folder:dotnet pack --output nupkgs
-
Pack the project in the current directory into the
nupkgs
folder and skip the build step:dotnet pack --no-build --output nupkgs
-
With the project's version suffix configured as
<VersionSuffix>$(VersionSuffix)</VersionSuffix>
in the .csproj file, pack the current project and update the resulting package version with the given suffix:dotnet pack --version-suffix "ci-1234"
-
Set the package version to
2.1.0
with thePackageVersion
MSBuild property:dotnet pack -p:PackageVersion=2.1.0
-
Pack the project for a specific target framework:
dotnet pack -p:TargetFrameworks=net45
-
Pack the project and use a specific runtime (Windows 10) for the restore operation:
dotnet pack --runtime win10-x64
-
Pack the project using a .nuspec file:
dotnet pack ~/projects/app1/project.csproj -p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget
For information about how to use
NuspecFile
,NuspecBasePath
, andNuspecProperties
, see the following resources: