dotnet-publish - Man Page

Publishes the application and its dependencies to a folder for deployment to a hosting system.

Examples (TL;DR)

dotnet publish

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

Synopsis

dotnet publish [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
    [-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>] [--use-current-runtime, --ucr [true|false]]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet publish -h|--help

Description

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:

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.

Implicit restore

You don’t have to run dotnet restore because it’s run implicitly by all commands that require a restore to occur, such as dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish, and dotnet pack. To disable implicit restore, use the --no-restore option.

The dotnet restore command is still useful in certain scenarios where explicitly restoring makes sense, such as continuous integration builds in Azure DevOps Services or in build systems that need to explicitly control when the restore occurs.

For information about how to manage NuGet feeds, see the dotnet restore documentation.

MSBuild

The dotnet publish command calls MSBuild, which invokes the Publish target. If the IsPublishable property is set to false for a particular project, the Publish target can’t be invoked, and the dotnet publish command only runs the implicit dotnet restore on the project.

Any parameters passed to dotnet publish are passed to MSBuild. The -c and -o parameters map to MSBuild’s Configuration and PublishDir properties, respectively.

The dotnet publish command accepts MSBuild options, such as -p for setting properties and -l to define a logger. For example, you can set an MSBuild property by using the format: -p:<NAME>=<VALUE>.

.pubxml files

You can also set publish-related properties by referring to a .pubxml file. For example:

dotnet publish -p:PublishProfile=FolderProfile

The preceding example uses the FolderProfile.pubxml file that is found in the <project_folder>/Properties/PublishProfiles folder. If you specify a path and file extension when setting the PublishProfile property, they’re ignored. MSBuild by default looks in the Properties/PublishProfiles folder and assumes the pubxml file extension. To specify the path and filename including extension, set the PublishProfileFullPath property instead of the PublishProfile property.

In the .pubxml file:

  • PublishUrl is used by Visual Studio to denote the Publish target.
  • PublishDir is used by the CLI to denote the Publish target.

If you want the scenario to work in all places, you can initialize both these properties to the same value in the .pubxml file. When GitHub issue dotnet/sdk#20931 (https://github.com/dotnet/sdk/issues/20931) is resolved, only one of these properties will need to be set.

Some properties in the .pubxml file are honored only by Visual Studio and have no effect on dotnet publish. We’re working to bring the CLI more into alignment with Visual Studio’s behavior. But some properties will never be used by the CLI. The CLI and Visual Studio both do the packaging aspect of publishing, and dotnet/sdk#29817 (https://github.com/dotnet/sdk/pull/29817) plans to add support for more properties related to that. But the CLI doesn’t do the deployment automation aspect of publishing, and properties related to that aren’t supported. The most notable .pubxml properties that aren’t supported by dotnet publish are the following ones that impact the build:

  • LastUsedBuildConfiguration
  • Configuration
  • Platform
  • LastUsedPlatform
  • TargetFramework
  • TargetFrameworks
  • RuntimeIdentifier
  • RuntimeIdentifiers

MSBuild properties

The following MSBuild properties change the output of dotnet publish.

  • PublishReadyToRun

    Compiles application assemblies as ReadyToRun (R2R) format. R2R is a form of ahead-of-time (AOT) compilation. For more information, see ReadyToRun images.

    To see warnings about missing dependencies that could cause runtime failures, use PublishReadyToRunShowWarnings=true.

    We recommend that you specify PublishReadyToRun in a publish profile rather than on the command line.

  • PublishSingleFile

    Packages the app into a platform-specific single-file executable. For more information about single-file publishing, see the single-file bundler design document (https://github.com/dotnet/designs/blob/main/accepted/2020/single-file/design.md).

    We recommend that you specify this option in the project file rather than on the command line.

  • PublishTrimmed

    Trims unused libraries to reduce the deployment size of an app when publishing a self-contained executable. For more information, see Trim self-contained deployments and executables. Available since .NET 6 SDK.

    We recommend that you specify this option in the project file rather than on the command line.

For more information, see the following resources:

  • MSBuild command-line reference
  • Visual Studio publish profiles (.pubxml) for ASP.NET Core app deployment
  • dotnet msbuild

Workload manifest downloads

When you run this command, it initiates an asynchronous background download of advertising manifests for workloads. If the download is still running when this command finishes, the download is stopped. For more information, see Advertising manifests.

Arguments

Options

Examples

See Also

Info

2023-10-25 .NET Documentation