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

Name

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

Synopsis

dotnet publish [<PROJECT>|<SOLUTION>|<FILE>] [-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>] [-p|--property:<PROPERTYNAME>=<VALUE>]    [-r|--runtime <RUNTIME_IDENTIFIER>]    [--sc|--self-contained] [--no-self-contained]    [-s|--source <SOURCE>] [--tl:[auto|on|off]]    [--ucr|--use-current-runtime]    [-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:

• Intermediate Language (IL) code in an assembly with adll 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.

Thedotnet 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.NET application publishing overview.

Implicit restore

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

Thedotnet restore command is still useful in certain scenarios where explicitly restoring makes sense, such ascontinuous 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 thedotnet restore documentation.

MSBuild

Thedotnet publish command calls MSBuild, which invokes thePublish target. If theIsPublishable property is set tofalse for a particular project, thePublish target can't be invoked, and thedotnet publish command only runs the implicitdotnet restore on the project.

Any parameters passed todotnet publish are passed to MSBuild. The-c and-o parameters map to MSBuild'sConfiguration andPublishDir properties, respectively.

Thedotnet 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 theFolderProfile.pubxml file that is found in the<project_folder>/Properties/PublishProfiles folder. If you specify a path and file extension when setting thePublishProfile property, they're ignored. MSBuild by default looks in theProperties/PublishProfiles folder and assumes thepubxml file extension. To specify the path and filename including extension, set thePublishProfileFullPath property instead of thePublishProfile 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 issuedotnet/sdk#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 ondotnet 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, anddotnet/sdk#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 bydotnet 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 ofdotnet publish.

• PublishReadyToRun

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

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

  We recommend that you specifyPublishReadyToRun 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 thesingle-file bundler design document. When this property is set totrue, thePublishSelfContained property is implicitly set totrue.

  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, seeTrim 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, seeAdvertising manifests.

Arguments

PROJECT | SOLUTION | FILE

The project or solution or C# (file-based app) file to operate on. If a file isn't specified, MSBuild searches the current directory for a project or solution.

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

• SOLUTION is the path and filename of a solution file (.sln or.slnx extension), or the path to a directory that contains a solution file.

• FILE is an argument added in .NET 10. The path and filename of a file-based app. File-based apps are contained within a single file that is built and run without a corresponding project (.csproj) file. For more information, seeBuild file-based C# apps.

Options

• -a|--arch <ARCHITECTURE>

  Specifies the target architecture. This is a shorthand syntax for setting theRuntime Identifier (RID), where the provided value is combined with the default RID. For example, on awin-x64 machine, specifying--arch x86 sets the RID towin-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 seeArtifacts 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 theRelease configuration by default for projects whose TargetFramework is set tonet8.0 or a later version. The default build configuration isDebug 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 specifiedtarget 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 theproject.assets.json file.

• --interactive

  Allows the command to stop and wait for user input or action. For example, to complete authentication.

• --manifest <PATH_TO_MANIFEST_FILE>

  Specifies one or severaltarget manifests to use to trim the set of packages published with the app. The manifest file is part of the output of thedotnet 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, successivedotnet publish commands result in nested output folders. For example, if the project folder ismyproject, and the publish output folder ismyproject/publish, and you rundotnet publish twice, the second run puts content files such as.config and.json files inmyproject/publish/publish. To avoid nesting publish folders, specify a publish folder that isn'tdirectly under the project folder, or exclude the publish folder from the project. To exclude a publish folder namedpublishoutput, add the following element to aPropertyGroup 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, seeSolution-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 msbuildPublishDir property instead of the--output option. For example,dotnet publish -p:PublishDir=.\publish sends publish output for each project to apublish folder under the folder that contains the project file.

• --os <OS>

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

• --sc|--self-contained

  Publish the .NET runtime with your application so the runtime doesn't need to be installed on the target machine.

• -p|--property:<PROPERTYNAME>=<VALUE>

  Sets one or more MSBuild properties. Specify multiple properties delimited by semicolons or by repeating the option:

  --property:<NAME1>=<VALUE1>;<NAME2>=<VALUE2>--property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>

• --no-self-contained

  Publish your application as a framework-dependent application. A compatible .NET runtime must be installed on the target machine to run your application.

• --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 theRID catalog. For more information, see.NET application publishing overview. If you use this option, use--self-contained or--no-self-contained also.

  Note

  Publishing can be done on thesolution level and on the singleproject level. When publishing from thesolution level by specifying the optional<SOLUTION> parameter or leaving it default, MSBuild first compiles the output into thepublish directorywithout any symbols. This means that later compilations done by MSBuild, based on the initial compilation, will still not include any details for specified<RUNTIME_IDENTIFIER>.

  This is expected behavior. To avoid this behavior either publish for a single project by specifying the optional<PROJECT> parameter for your RID or specify RIDs directly in the project config by adding the<RuntimeIdentifiers> property.

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

  Specifies whetherTerminal Logger should be used for the build output. The default isauto, 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.

  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.

• --ucr|--use-current-runtime

  Use the current runtime as the target runtime.

• -v|--verbosity <LEVEL>

  Sets the verbosity level of the command. Allowed values areq[uiet],m[inimal],n[ormal],d[etailed], anddiag[nostic]. The default isminimal. For more information, seeLoggerVerbosity.

• --version-suffix <VERSION_SUFFIX>

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

• -?|-h|--help

  Prints out a description of how to use the command.

Examples

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

  dotnet publish

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

• Create aself-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 aframework-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

• Publish the file-based C# programapp.cs in the current directory:

  dotnet publish app.cs

  File-based program support was added in .NET SDK 10.0.100.

See also

• .NET application publishing overview
• 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