This topic applies to: ✓ .NET Core SDK 1.x ✓ .NET Core SDK 2.x
dotnet publish - Packs the application and its dependencies into a folder for deployment to a hosting system.
dotnet publish [<PROJECT>] [-c|--configuration] [-f|--framework] [--force] [--manifest] [--no-build] [--no-dependencies] [--no-restore] [-o|--output] [-r|--runtime] [--self-contained] [-v|--verbosity] [--version-suffix] dotnet publish [-h|--help]
dotnet publish compiles the application, reads through its dependencies specified in the project file, and publishes the resulting set of files to a directory. The output includes the following assets:
- Intermediate Language (IL) code in an assembly with a dll extension.
- .deps.json file that includes all of the dependencies of the project.
- .runtime.config.json file that specifies the shared runtime that the application expects, as well as other configuration options for the runtime (for example, garbage collection type).
- The application's dependencies, which are copied from the NuGet cache into the output folder.
dotnet publish command's output is ready for deployment to a hosting system (for example, a server, PC, Mac, laptop) for execution. It's the only officially supported way to prepare the application for deployment. Depending on the type of deployment that the project specifies, the hosting system may or may not have the .NET Core shared runtime installed on it. For more information, see .NET Core Application Deployment. For the directory structure of a published application, see Directory structure.
Starting with .NET Core 2.0, you don't have to run
dotnet restore because it's run implicitly by all commands, such as
dotnet build and
dotnet run, that require a restore to occur. It's still a valid command in certain scenarios where doing an explicit restore makes sense, such as continuous integration builds in Azure DevOps Services or in build systems that need to explicitly control the time at which the restore occurs.
This command also supports the
dotnet restore options when passed in the long form (for example,
--source). Short form options, such as
-s, are not supported.
The project to publish. If not specified, it defaults to the current directory.
Defines the build configuration. The default value is
Publishes the application for the specified target framework. You must specify the target framework in the project file.
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.
Prints out a short help for the command.
Specifies one or several target manifests to use to trim the set of packages published with the app. The manifest file is part of the output of the
dotnet store command. To specify multiple manifests, add a
--manifest option for each manifest. This option is available starting with .NET Core 2.0 SDK.
Doesn't build the project before publishing. It also implicitly sets the
Ignores project-to-project references and only restores the root project.
Doesn't execute an implicit restore when running the command.
Specifies the path for the output directory. If not specified, it defaults to ./bin/[configuration]/[framework]/publish/ for a framework-dependent deployment or ./bin/[configuration]/[framework]/[runtime]/publish/ for a self-contained deployment. If the path is relative, the output directory generated is relative to the project file location, not to the current working directory.
Publishes the .NET Core runtime with your application so the runtime doesn't need to be installed on the target machine. If a runtime identifier is specified, its default value is
true. For more information about the different deployment types, see .NET Core application deployment.
Publishes the application for a given runtime. This is used when creating a self-contained deployment (SCD). For a list of Runtime Identifiers (RIDs), see the RID catalog. Default is to publish a framework-dependent deployment (FDD).
Sets the verbosity level of the command. Allowed values are
Defines the version suffix to replace the asterisk (
*) in the version field of the project file.
Publish the project in the current directory:
Publish the application using the specified project file:
dotnet publish ~/projects/app1/app1.csproj
Publish the project in the current directory using the
dotnet publish --framework netcoreapp1.1
Publish the current application using the
netcoreapp1.1 framework and the runtime for
OS X 10.10 (you must list this RID in the project file).
dotnet publish --framework netcoreapp1.1 --runtime osx.10.11-x64
Publish the current application but don't restore project-to-project (P2P) references, just the root project during the restore operation (.NET Core SDK 2.0 and later versions):
dotnet publish --no-dependencies