Partilhar via

dotnet publish

Este artigo aplica-se a: ✔️ .NET 6 SDK e versões posteriores

Designação

dotnet publish - Publica o aplicativo e suas dependências em uma pasta para implantação em um sistema de hospedagem.

Sinopse

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

Descrição

dotnet publish compila o aplicativo, lê suas dependências especificadas no arquivo de projeto e publica o conjunto resultante de arquivos em um diretório. A produção inclui os seguintes ativos:

  • Código IL (Intermediate Language) em um assembly com uma extensão de dll .
  • Um arquivo .deps.json que inclui todas as dependências do projeto.
  • Um arquivo .runtimeconfig.json que especifica o tempo de execução compartilhado que o aplicativo espera, bem como outras opções de configuração para o tempo de execução (por exemplo, tipo de coleta de lixo).
  • As dependências do aplicativo, que são copiadas do cache do NuGet para a pasta de saída.

A saída do comando dotnet publish está pronta para implantação em um sistema de hospedagem (por exemplo, um servidor, PC, Mac, laptop) para execução. É a única maneira oficialmente suportada de preparar o aplicativo para implantação. Dependendo do tipo de implantação que o projeto especifica, o sistema de hospedagem pode ou não ter o tempo de execução compartilhado do .NET instalado nele. Para obter mais informações, consulte Visão geral de publicação de aplicativos .NET.

Restauração implícita

Não é necessário executádotnet restore porque ele é executado implicitamente por todos os comandos que exigem uma restauração para ocorrer, como dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishe dotnet pack. Para desativar a restauração implícita, use a opção --no-restore.

O comando dotnet restore ainda é útil em determinados cenários em que a restauração explícita faz sentido, como compilações de integração contínua no de Serviços de DevOps do Azure ou em sistemas de compilação que precisam controlar explicitamente quando a restauração ocorre.

Para obter informações sobre como gerenciar feeds NuGet, consulte a documentação dotnet restore.

MSBuild

O comando dotnet publish chama MSBuild, que invoca o destino Publish. Se o de propriedade estiver definido como para um projeto específico, o destino não poderá ser invocado e o comando executará apenas o de restauração de dotnet implícito no projeto.

Todos os parâmetros passados para dotnet publish são passados para o MSBuild. Os parâmetros -c e -o são mapeados para as propriedades Configuration e PublishDir do MSBuild, respectivamente.

O comando dotnet publish aceita opções do MSBuild, como -p para definir propriedades e -l para definir um registrador. Por exemplo, você pode definir uma propriedade MSBuild usando o formato: -p:<NAME>=<VALUE>.

Arquivos .pubxml

Você também pode definir propriedades relacionadas à publicação fazendo referência a um arquivo de .pubxml . Por exemplo:

dotnet publish -p:PublishProfile=FolderProfile

O exemplo anterior usa o arquivo de FolderProfile.pubxml encontrado na pasta project_folder/Properties/PublishProfiles. Se você especificar um caminho e uma extensão de arquivo ao definir a propriedade PublishProfile, eles serão ignorados. MSBuild por padrão procura na pasta Properties/PublishProfiles e assume a extensão de arquivo pubxml . Para especificar o caminho e o nome do arquivo, incluindo a extensão, defina a propriedade PublishProfileFullPath em vez da propriedade PublishProfile.

No arquivo .pubxml:

  • PublishUrl é usado pelo Visual Studio para indicar o destino Publicar.
  • PublishDir é usado pela CLI para indicar o destino Publicar.

Se desejar que o cenário funcione em todos os locais, você poderá inicializar ambas as propriedades com o mesmo valor no arquivo de .pubxml . Quando o problema do GitHub dotnet/sdk#20931 for resolvido, apenas uma dessas propriedades precisará ser definida.

Algumas propriedades no arquivo .pubxml são honradas apenas pelo Visual Studio e não têm efeito sobre dotnet publish. Estamos trabalhando para alinhar a CLI com o comportamento do Visual Studio. Mas algumas propriedades nunca serão usadas pela CLI. A CLI e o Visual Studio fazem o aspeto de empacotamento da publicação, e dotnet/sdk#29817 planeja adicionar suporte para mais propriedades relacionadas a isso. Mas a CLI não faz o aspeto de automação de implantação da publicação, e as propriedades relacionadas a isso não são suportadas. As propriedades de .pubxml mais notáveis que não são suportadas pelo são as seguintes que afetam a compilação:

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

Propriedades do MSBuild

As seguintes propriedades do MSBuild alteram a saída de dotnet publish.

  • PublishReadyToRun

    Compila assemblies de aplicativos como formato ReadyToRun (R2R). R2R é uma forma de compilação ahead-of-time (AOT). Para obter mais informações, consulte imagens ReadyToRun.

    Para ver avisos sobre dependências ausentes que podem causar falhas de tempo de execução, use PublishReadyToRunShowWarnings=true.

    Recomendamos que você especifique PublishReadyToRun em um perfil de publicação em vez de na linha de comando.

  • PublishSingleFile

    Empacota o aplicativo em um executável de arquivo único específico da plataforma. Para obter mais informações sobre publicação de arquivo único, consulte o documento de design do empacotador de arquivo único. Quando esta propriedade é definida como true, a PublishSelfContained propriedade é implicitamente definida como true.

    Recomendamos que você especifique essa opção no arquivo de projeto em vez de na linha de comando.

  • PublishTrimmed

    Corta bibliotecas não utilizadas para reduzir o tamanho de implantação de um aplicativo ao publicar um executável independente. Para obter mais informações, consulte Cortar implantações independentes e executáveis. Disponível desde o SDK do .NET 6.

    Recomendamos que você especifique essa opção no arquivo de projeto em vez de na linha de comando.

Para obter mais informações, consulte os seguintes recursos:

Downloads de manifesto de carga de trabalho

Quando você executa esse comando, ele inicia um download assíncrono em segundo plano de manifestos de publicidade para cargas de trabalho. Se o download ainda estiver em execução quando este comando terminar, o download será interrompido. Para obter mais informações, consulte Manifestos de publicidade.

Argumentos

PROJECT | SOLUTION | FILE

O projeto ou solução ou arquivo C# (aplicativo baseado em arquivo) para operar. Se um arquivo não for especificado, o MSBuild procurará um projeto ou solução no diretório atual.

  • PROJECT é o caminho e o nome do arquivo de projeto de um C#, F# ou Visual Basic ou o caminho para um diretório que contém um arquivo de projeto C#, F# ou Visual Basic.

  • SOLUTION é o caminho e o nome do arquivo de solução (.sln ou extensão .slnx) ou o caminho para um diretório que contém um arquivo de solução.

  • FILE é um argumento adicionado no .NET 10. O caminho e o nome do arquivo de um aplicativo baseado em arquivo. Os aplicativos baseados em arquivo estão contidos em um único arquivo que é criado e executado sem um arquivo de projeto correspondente (.csproj). Para obter mais informações, consulte Criar aplicativos C# baseados em arquivo.

Opções

  • -a|--arch <ARCHITECTURE>

    Especifica a arquitetura de destino. Esta é uma sintaxe abreviada para definir o Runtime Identifier (RID), onde o valor fornecido é combinado com o RID padrão. Por exemplo, em uma máquina win-x64, especificar --arch x86 define o RID como win-x86. Se você usar essa opção, não use a opção -r|--runtime. Disponível desde o .NET 6 Preview 7.

  • --artifacts-path <ARTIFACTS_DIR>

    Todos os arquivos de saída de compilação do comando executado irão em subpastas sob o caminho especificado, separados por projeto. Para obter mais informações, consulte Layout de saída de artefatos. Disponível desde o SDK do .NET 8.

  • -c|--configuration <CONFIGURATION>

    Define a configuração de compilação. Se você estiver desenvolvendo com o SDK do .NET 8 ou uma versão posterior, o comando usará a configuração Release por padrão para projetos cujo TargetFramework está definido como net8.0 ou uma versão posterior. A configuração de compilação padrão é Debug para versões anteriores do SDK e para estruturas de destino anteriores. Você pode substituir o padrão nas configurações do projeto ou usando essa opção. Para obter mais informações, consulte 'dotnet publish' usa o de configuração Release e 'dotnet pack' usa Release configuration.

  • --disable-build-servers

    Força o comando a ignorar quaisquer servidores de compilação persistentes. Essa opção fornece uma maneira consistente de desabilitar todo o uso do cache de compilação, o que força uma compilação do zero. Uma compilação que não depende de caches é útil quando os caches podem estar corrompidos ou incorretos por algum motivo. Disponível desde .NET 7 SDK.

  • -f|--framework <FRAMEWORK>

    Publica o aplicativo para a estrutura de destino especificada. Você deve especificar a estrutura de destino no arquivo de projeto.

  • --force

    Força todas as dependências a serem resolvidas, mesmo que a última restauração tenha sido bem-sucedida. Especificar esse sinalizador é o mesmo que excluir o arquivo project.assets.json.

  • --interactive

    Permite que o comando pare e aguarde a entrada ou ação do usuário. Por exemplo, para concluir a autenticação.

  • --manifest <PATH_TO_MANIFEST_FILE>

    Especifica um ou vários manifestos de destino usar para cortar o conjunto de pacotes publicados com o aplicativo. O arquivo de manifesto faz parte da saída do comando dotnet store. Para especificar vários manifestos, adicione uma opção --manifest para cada manifesto.

  • --no-build

    Não cria o projeto antes de publicar. Também estabelece implicitamente a bandeira --no-restore.

  • --no-dependencies

    Ignora referências de projeto para projeto e restaura apenas o projeto raiz.

  • --nologo

    Não exibe o banner de inicialização ou a mensagem de direitos autorais.

  • --no-restore

    Não executa uma restauração implícita ao executar o comando.

  • -o|--output <OUTPUT_DIRECTORY>

    Especifica o caminho para o diretório de saída.

    Se não for especificado, o padrão será [project_file_folder]/bin/[configuration]/[framework]/publish/ para um executável dependente da estrutura e binários entre plataformas. O padrão é [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ para um executável independente.

    Em um projeto da Web, se a pasta de saída estiver na pasta do projeto, os comandos dotnet publish sucessivos resultarão em pastas de saída aninhadas. Por exemplo, se a pasta do projeto estiver myproject, e a pasta de saída publish for myproject/publish, e você executar dotnet publish duas vezes, a segunda execução colocará arquivos de conteúdo, como arquivos .config e .json, em myproject/publish/publish. Para evitar aninhar pastas de publicação, especifique uma pasta de publicação que não esteja diretamente na pasta do projeto ou exclua a pasta de publicação do projeto. Para excluir uma pasta de publicação chamada publishoutput, adicione o seguinte elemento a um elemento no arquivo de .csproj do :

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

    • SDK do .NET 7.0.200 e posterior

      Se você especificar a opção --output ao executar esse comando em uma solução, a CLI emitirá um aviso (um erro em 7.0.200) devido à semântica pouco clara do caminho de saída. A opção --output não é permitida porque todas as saídas de todos os projetos construídos seriam copiadas para o diretório especificado, o que não é compatível com projetos com vários destinos, bem como projetos que têm versões diferentes de dependências diretas e transitivas. Para obter mais informações, consulte opção de --output no nível da solução não é mais válida para comandos relacionados à compilação.

    • SDK do .NET Core 3.x e posterior

      Se você especificar um caminho relativo ao publicar um projeto, o diretório de saída gerado será relativo ao diretório de trabalho atual, não ao local do arquivo de projeto.

      Se você especificar um caminho relativo ao publicar uma solução, toda a saída de todos os projetos irá para a pasta especificada relativa ao diretório de trabalho atual. Para fazer com que a saída de publicação vá para pastas separadas para cada projeto, especifique um caminho relativo usando a propriedade msbuild PublishDir em vez da opção --output. Por exemplo, dotnet publish -p:PublishDir=.\publish envia a saída de publicação de cada projeto para uma pasta publish na pasta que contém o arquivo de projeto.

  • --os <OS>

    Especifica o sistema operacional (SO) de destino. Esta é uma sintaxe abreviada para definir o Runtime Identifier (RID), onde o valor fornecido é combinado com o RID padrão. Por exemplo, em uma máquina win-x64, especificar --os linux define o RID como linux-x64. Se você usar essa opção, não use a opção -r|--runtime. Disponível desde .NET 6.

  • --sc|--self-contained

    Publique o tempo de execução do .NET com seu aplicativo para que o tempo de execução não precise ser instalado na máquina de destino.

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

    Define uma ou mais propriedades do MSBuild. Especifique várias propriedades delimitadas por ponto-e-vírgula ou repetindo a opção:

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

  • --no-self-contained

    Publique a sua candidatura como uma aplicação dependente do framework. Um tempo de execução .NET compatível deve ser instalado na máquina de destino para executar seu aplicativo.

  • --source <SOURCE>

    O URI da origem do pacote NuGet a ser usado durante a operação de restauração.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Publica o aplicativo para um determinado tempo de execução. Para obter uma lista de identificadores de tempo de execução (RIDs), consulte o catálogo RID. Para obter mais informações, consulte Visão geral de publicação de aplicativos .NET. Se você usar essa opção, use --self-contained ou --no-self-contained também.

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

    Especifica se o Terminal Logger deve ser usado para a saída de compilação. O padrão é auto, que primeiro verifica o ambiente antes de habilitar o registro em log do terminal. A verificação de ambiente verifica se o terminal é capaz de usar recursos de saída modernos e não está usando uma saída padrão redirecionada antes de ativar o novo registrador. on ignora a verificação do ambiente e habilita o registro do terminal. off ignora a verificação de ambiente e usa o registrador de console padrão.

    O Terminal Logger mostra a fase de restauração seguida pela fase de compilação. Durante cada fase, os projetos atualmente em construção aparecem na parte inferior do terminal. Cada projeto que está construindo produz tanto a meta do MSBuild que está sendo criada quanto a quantidade de tempo gasto nessa meta. Você pode pesquisar essas informações para saber mais sobre a compilação. Quando um projeto termina de construir, uma única seção "construção concluída" é escrita que captura:

    • O nome do projeto construído.
    • A estrutura de destino (se multidirecionada).
    • O status dessa compilação.
    • A saída primária dessa compilação (que é hiperligada).
    • Qualquer diagnóstico gerado para esse projeto.

    Esta opção está disponível a partir do .NET 8.

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

    Use o tempo de execução atual como o tempo de execução de destino.

  • -v|--verbosity <LEVEL>

    Define o nível de detalhamento do comando. Os valores permitidos são q[uiet], m[inimal], n[ormal], d[etailed]e diag[nostic]. O padrão é minimal. Para obter mais informações, consulte LoggerVerbosity.

  • --version-suffix <VERSION_SUFFIX>

    Define o sufixo de versão para substituir o asterisco (*) no campo de versão do arquivo de projeto.

  • -?|-h|--help

    Imprime uma descrição de como usar o comando.

Exemplos

  • Crie um binário de plataforma cruzada dependente da estrutura para o projeto no diretório atual:

    dotnet publish

    A partir do SDK do .NET Core 3.0, este exemplo também cria um executável dependente do Framework para a plataforma atual.

  • Crie um executável independente para o projeto no diretório atual, para um tempo de execução específico:

    dotnet publish --runtime osx-x64

    O RID deve estar no arquivo de projeto.

  • Crie um executável dependente da estrutura para o projeto no diretório atual, para uma plataforma específica:

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

    O RID deve estar no arquivo de projeto. Este exemplo se aplica ao SDK do .NET Core 3.0 e versões posteriores.

  • Publique o projeto no diretório atual, para um tempo de execução específico e estrutura de destino:

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

  • Publique o arquivo de projeto especificado:

    dotnet publish ~/projects/app1/app1.csproj

  • Publique o aplicativo atual, mas não restaure referências P2P (projeto a projeto), apenas o projeto raiz durante a operação de restauração:

    dotnet publish --no-dependencies

  • Publique o programa C# baseado em arquivo app.cs no diretório atual:

    dotnet publish app.cs

    O suporte a programas baseados em arquivo foi adicionado no .NET SDK 10.0.100.

Ver também

  • Last updated on