LinuxCommandLibrary

dotnet-publish

Package .NET application for deployment

TLDR

Compile a .NET project in release mode

$ dotnet publish [[-c|--configuration]] Release [path/to/project_file]
copy

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]
copy

Package the application into a platform-specific single-file executable
$ dotnet publish [[-r|--runtime]] [runtime_identifier] -p:PublishSingleFile=true [path/to/project_file]
copy

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]
copy

Compile a .NET project without restoring dependencies
$ dotnet publish --no-restore [path/to/project_file]
copy

Specify the output directory
$ dotnet publish [[-o|--output]] [path/to/directory] [path/to/project_file]
copy

SYNOPSIS

dotnet publish [project] [options]

PARAMETERS

[project]
    The path to the project file (.csproj) to publish. If not specified, it defaults to the current directory.

-c|--configuration
    The build configuration to use (e.g., Debug or Release). Defaults to Debug.

-f|--framework
    The target framework to publish for (e.g., net6.0, net7.0). Must be specified in the project file.

-r|--runtime
    The target runtime to publish for (e.g., win-x64, linux-x64). Enables self-contained deployment.
Use `dotnet --info` to see available runtimes.

--no-restore
    Doesn't execute an implicit restore during publish. Use if you've already restored the project.

--no-build
    Doesn't build the project before publishing.

-o|--output
    The output directory for the published files. If not specified, it defaults to bin/Release/[framework]/publish or bin/Debug/[framework]/publish.

--self-contained [true|false]
    Publishes the .NET runtime with your application, making it self-contained. Defaults to `true` if `--runtime` is specified, otherwise `false`.

--nologo
    Suppresses the display of the .NET SDK logo.

-v|--verbosity
    Sets the verbosity level of the command. Allowed values are `q[uiet]`, `m[inimal]`, `n[ormal]`, `d[etailed]`, and `diag[nostic]`.

--force
    Forces all dependencies to be resolved even if the last restore was successful. This is equivalent to deleting the project.assets.json file.

--manifest
    Specifies a manifest file to use for the publish operation.

--source
    Specifies a NuGet package source to use during restore.

--version-suffix
    Sets the version suffix to use when publishing.

--disable-parallel
    Disables parallel project building.

DESCRIPTION

The `dotnet publish` command builds a .NET application and its dependencies into a deployable format. This process involves compiling the code, resolving NuGet package dependencies, and copying the necessary files (executables, libraries, configuration files, and assets) into a publish directory. This directory then contains everything needed to run the application on a target environment, without requiring the .NET SDK to be installed on that environment (self-contained deployment) or relying on a globally installed .NET runtime (framework-dependent deployment). The type of deployment is controlled by project settings and command-line options. It supports cross-platform publishing, allowing you to create deployment packages for different operating systems and architectures from a single development environment.

This command is crucial for preparing .NET applications for various deployment scenarios, including web servers, cloud platforms, and standalone desktop applications.
By default, the publish command produces a framework-dependent deployment, which requires the .NET runtime to be installed on the target system. However, it can also be configured to create self-contained deployments, which bundle the .NET runtime with the application.
It streamlines the deployment process and provides a consistent and reliable way to package .NET applications.

CAVEATS

Self-contained deployments are significantly larger than framework-dependent deployments because they include the .NET runtime.
Cross-platform publishing requires a specific runtime identifier (-r) for each target platform. Incorrect configurations can lead to errors during deployment.

DEPLOYMENT TYPES

There are two main types of deployments: Framework-Dependent Deployments (FDD) and Self-Contained Deployments (SCD). FDDs require the .NET runtime to be installed on the target machine, reducing the size of the published output. SCDs bundle the runtime with the application, making it independent of the target machine's runtime environment but increasing the size. SCD is enabled with the `--runtime` parameter.

RUNTIME IDENTIFIERS (RIDS)

A Runtime Identifier (RID) is a string that identifies the target operating system and processor architecture. Examples include `win-x64`, `linux-x64`, and `osx-x64`. RIDs are crucial for creating self-contained deployments and for specifying platform-specific dependencies. A complete list of RIDs is available in the .NET documentation. Using the correct RID is very important for successful builds.

PUBLISHING WEB APPLICATIONS

When publishing web applications, the `dotnet publish` command will typically copy all the necessary files (including static assets like HTML, CSS, and JavaScript files) to the output directory. The application can then be deployed to a web server (e.g., IIS, Apache, Nginx) or a cloud platform (e.g., Azure, AWS).

HISTORY

The `dotnet publish` command was introduced with the .NET Core CLI as part of the shift towards a cross-platform, modular .NET development experience. It replaced more complex deployment mechanisms from previous .NET Framework versions, offering a unified approach to packaging applications for deployment across different operating systems and architectures. Its development has been ongoing, with improvements to performance, support for new platforms, and integration with various deployment workflows. It is central part of the .NET development lifecycle.

SEE ALSO

dotnet build(1), dotnet restore(1), dotnet run(1)

Copied to clipboard