dotnet-publish - Man Page

• Compile a .NET project in release mode: dotnet publish [-c|--configuration] Release path/to/project_file
• Publish the .NET Core runtime with your application for the specified runtime: dotnet publish [-sc|--self-contained] true [-r|--runtime] runtime_identifier path/to/project_file
• Package the application into a platform-specific single-file executable: dotnet publish [-r|--runtime] runtime_identifier -p:PublishSingleFile=true path/to/project_file
• Trim unused libraries to reduce the deployment size of an application: dotnet publish [-sc|--self-contained] true [-r|--runtime] runtime_identifier -p:PublishTrimmed=true path/to/project_file
• Compile a .NET project without restoring dependencies: dotnet publish --no-restore path/to/project_file
• Specify the output directory: dotnet publish [-o|--output] path/to/directory path/to/project_file

tldr.sh

This article applies to: ✔️ .NET Core 3.1 SDK and later versions

dotnet publish [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>] [--disable-build-servers]
    [-f|--framework <FRAMEWORK>] [--force] [--interactive]
    [--manifest <PATH_TO_MANIFEST_FILE>] [--no-build] [--no-dependencies]
    [--no-restore] [--nologo] [-o|--output <OUTPUT_DIRECTORY>]
    [--os <OS>] [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--sc|--self-contained [true|false]] [--no-self-contained]
    [-s|--source <SOURCE>] [--tl:[auto|on|off]]
    [--use-current-runtime, --ucr [true|false]]
    [-v|--verbosity <LEVEL>] [--version-suffix <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.
• A .deps.json file that includes all of the dependencies of the project.
• A .runtimeconfig.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.

The 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 shared runtime installed on it. For more information, see Publish .NET apps with the .NET CLI.

dotnet publish -p:PublishProfile=FolderProfile

• PROJECT|SOLUTION

  The project or solution to publish.

  • PROJECT is the path and filename of a C#, F#, or Visual Basic project file, or the path to a directory that contains a C#, F#, or Visual Basic project file. If the directory is not specified, it defaults to the current directory.
  • SOLUTION is the path and filename of a solution file (.sln extension), or the path to a directory that contains a solution file. If the directory is not specified, it defaults to the current directory.

• -a|--arch <ARCHITECTURE>

  Specifies the target architecture. This is a shorthand syntax for setting the Runtime Identifier (RID), where the provided value is combined with the default RID. For example, on a win-x64 machine, specifying --arch x86 sets the RID to win-x86. If you use this option, don’t use the -r|--runtime option. Available since .NET 6 Preview 7.

• --artifacts-path <ARTIFACTS_DIR>

  All build output files from the executed command will go in subfolders under the specified path, separated by project. For more information see Artifacts Output Layout. Available since .NET 8 SDK.

• -c|--configuration <CONFIGURATION>

  Defines the build configuration. If you’re developing with the .NET 8 SDK or a later version, the command uses the Release configuration by default for projects whose TargetFramework is set to net8.0 or a later version. The default build configuration is Debug for earlier versions of the SDK and for earlier target frameworks. You can override the default in project settings or by using this option. For more information, see `dotnet publish' uses Release configuration and `dotnet pack' uses Release configuration.

• --disable-build-servers

  Forces the command to ignore any persistent build servers. This option provides a consistent way to disable all use of build caching, which forces a build from scratch. A build that doesn’t rely on caches is useful when the caches might be corrupted or incorrect for some reason. Available since .NET 7 SDK.

• -f|--framework <FRAMEWORK>

  Publishes the application for the specified target framework. You must specify the target framework in the project file.

• --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.

• -?|-h|--help

  Prints out a description of how to use the command.

• --interactive

  Allows the command to stop and wait for user input or action. For example, to complete authentication. Available since .NET Core 3.0 SDK.

• --manifest <PATH_TO_MANIFEST_FILE>

  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.

• --no-build

  Doesn’t build the project before publishing. It also implicitly sets the --no-restore flag.

• --no-dependencies

  Ignores project-to-project references and only restores the root project.

• --nologo

  Doesn’t display the startup banner or the copyright message.

• --no-restore

  Doesn’t execute an implicit restore when running the command.

• -o|--output <OUTPUT_DIRECTORY>

  Specifies the path for the output directory.

  If not specified, it defaults to [project_file_folder]/bin/[configuration]/[framework]/publish/ for a framework-dependent executable and cross-platform binaries. It defaults to [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ for a self-contained executable.

  In a web project, if the output folder is in the project folder, successive dotnet publish commands result in nested output folders. For example, if the project folder is myproject, and the publish output folder is myproject/publish, and you run dotnet publish twice, the second run puts content files such as .config and .json files in myproject/publish/publish. To avoid nesting publish folders, specify a publish folder that isn’t directly under the project folder, or exclude the publish folder from the project. To exclude a publish folder named publishoutput, add the following element to a PropertyGroup element in the .csproj file:

  <DefaultItemExcludes>$(DefaultItemExcludes);publishoutput**</DefaultItemExcludes>

  • .NET 7.0.200 SDK and later

    If you specify the --output option when running this command on a solution, the CLI will emit a warning (an error in 7.0.200) due to the unclear semantics of the output path. The --output option is disallowed because all outputs of all built projects would be copied into the specified directory, which isn’t compatible with multi-targeted projects, as well as projects that have different versions of direct and transitive dependencies. For more information, see Solution-level --output option no longer valid for build-related commands.

  • .NET Core 3.x SDK and later

    If you specify a relative path when publishing a project, the generated output directory is relative to the current working directory, not to the project file location.

    If you specify a relative path when publishing a solution, all output for all projects goes into the specified folder relative to the current working directory. To make publish output go to separate folders for each project, specify a relative path by using the msbuild PublishDir property instead of the --output option. For example, dotnet publish -p:PublishDir=.\publish sends publish output for each project to a publish folder under the folder that contains the project file.

  • .NET Core 2.x SDK

    If you specify a relative path when publishing a project, the generated output directory is relative to the project file location, not to the current working directory.

    If you specify a relative path when publishing a solution, each project’s output goes into a separate folder relative to the project file location. If you specify an absolute path when publishing a solution, all publish output for all projects goes into the specified folder.

• --os <OS>

  Specifies the target operating system (OS). This is a shorthand syntax for setting the Runtime Identifier (RID), where the provided value is combined with the default RID. For example, on a win-x64 machine, specifying --os linux sets the RID to linux-x64. If you use this option, don’t use the -r|--runtime option. Available since .NET 6.

• --sc|--self-contained [true|false]

  Publishes the .NET runtime with your application so the runtime doesn’t need to be installed on the target machine. Default is true if a runtime identifier is specified and the project is an executable project (not a library project). For more information, see .NET application publishing and Publish .NET apps with the .NET CLI.

  If this option is used without specifying true or false, the default is true. In that case, don’t put the solution or project argument immediately after --self-contained, because true or false is expected in that position.

• --no-self-contained

  Equivalent to --self-contained false.

• --source <SOURCE>

  The URI of the NuGet package source to use during the restore operation.

• -r|--runtime <RUNTIME_IDENTIFIER>

  Publishes the application for a given runtime. For a list of Runtime Identifiers (RIDs), see the RID catalog. For more information, see .NET application publishing and Publish .NET apps with the .NET CLI. If you use this option, use --self-contained or --no-self-contained also.

• --tl:[auto|on|off]

  Specifies whether the terminal logger should be used for the build output. The default is auto, which first verifies the environment before enabling terminal logging. The environment check verifies that the terminal is capable of using modern output features and isn’t using a redirected standard output before enabling the new logger. on skips the environment check and enables terminal logging. off skips the environment check and uses the default console logger.

  The terminal logger shows you the restore phase followed by the build phase. During each phase, the currently building projects appear at the bottom of the terminal. Each project that’s building outputs both the MSBuild target currently being built and the amount of time spent on that target. You can search this information to learn more about the build. When a project is finished building, a single “build completed” section is written that captures:

  • The name of the built project.
  • The target framework (if multi-targeted).
  • The status of that build.
  • The primary output of that build (which is hyperlinked).
  • Any diagnostics generated for that project.

  This option is available starting in .NET 8.

• --use-current-runtime, --ucr [true|false]

  Sets the RuntimeIdentifier to a platform portable RuntimeIdentifier based on the one of your machine. This happens implicitly with properties that require a RuntimeIdentifier, such as SelfContained, PublishAot, PublishSelfContained, PublishSingleFile, and PublishReadyToRun. If the property is set to false, that implicit resolution will no longer occur.

• -v|--verbosity <LEVEL>

  Sets the verbosity level of the command. Allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. The default is minimal. For more information, see <xref:Microsoft.Build.Framework.LoggerVerbosity>.

• --version-suffix <VERSION_SUFFIX>

  Defines the version suffix to replace the asterisk (*) in the version field of the project file.

• Create a framework-dependent cross-platform binary for the project in the current directory:

  dotnet publish

  Starting with .NET Core 3.0 SDK, this example also creates a framework-dependent executable for the current platform.

• Create a self-contained executable for the project in the current directory, for a specific runtime:

  dotnet publish --runtime osx-x64

  The RID must be in the project file.

• Create a framework-dependent executable for the project in the current directory, for a specific platform:

  dotnet publish --runtime osx-x64 --self-contained false

  The RID must be in the project file. This example applies to .NET Core 3.0 SDK and later versions.

• Publish the project in the current directory, for a specific runtime and target framework:

  dotnet publish --framework net8.0 --runtime osx-x64

• Publish the specified project file:

  dotnet publish ~/projects/app1/app1.csproj

• Publish the current application but don’t restore project-to-project (P2P) references, just the root project during the restore operation:

  dotnet publish --no-dependencies

• .NET application publishing overview
• Publish .NET apps with the .NET CLI
• Target frameworks
• Runtime Identifier (RID) catalog
• Containerize a .NET app with dotnet publish
• Working with macOS Catalina Notarization
• Directory structure of a published application
• MSBuild command-line reference
• Visual Studio publish profiles (.pubxml) for ASP.NET Core app deployment
• dotnet msbuild
• Trim self-contained deployments