dotnet publicar

  • Artigo

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

Nome

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>] [-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>] [--tl:[auto|on|off]]
    [--use-current-runtime, --ucr [true|false]]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet publish -h|--help

Description

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 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 dotnet publish saída do comando 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 Publicar aplicativos .NET com a CLI do .NET.

Restauração implícita

Você não precisa executar 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 --no-restore opção.

O dotnet restore comando ainda é útil em determinados cenários em que a restauração explícita faz sentido, como compilações de integração contínua nos 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 dotnet restore documentação.

MSBuild

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

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

O dotnet publish comando 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 .pubxml . Por exemplo:

dotnet publish -p:PublishProfile=FolderProfile

O exemplo anterior usa o arquivo FolderProfile.pubxml encontrado na <pasta project_folder>/Properties/PublishProfiles . Se você especificar um caminho e uma extensão de arquivo ao definir a PublishProfile propriedade, 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 PublishProfileFullPath propriedade em vez da PublishProfile propriedade.

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 .pubxml . Quando o problema dotnet/sdk#20931 do GitHub 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 publisho . 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 .pubxml mais notáveis que não são suportadas são dotnet publish 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 do 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.

    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

    O projeto ou solução a publicar.

    • 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. Se o diretório não for especificado, o padrão será o diretório atual.

    • SOLUTION é o caminho e o nome do arquivo de solução (extensão .sln ) ou o caminho para um diretório que contém um arquivo de solução. Se o diretório não for especificado, o padrão será o diretório atual.

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 win-x64 máquina, especificar --arch x86 define o RID como win-x86. Se você usar essa opção, não use a -r|--runtime opção. Disponível desde o .NET 6 Preview 7.

  • -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 usa a Release configuração 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 a 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 .

  • -?|-h|--help

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

  • --interactive

    Permite que o comando pare e aguarde a entrada ou ação do usuário. Por exemplo, para concluir a autenticação. Disponível desde o SDK do .NET Core 3.0.

  • --manifest <PATH_TO_MANIFEST_FILE>

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

  • --no-build

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

  • --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 de 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 Web, se a pasta de saída estiver na pasta do projeto, comandos sucessivos dotnet publish resultarão em pastas de saída aninhadas. Por exemplo, se a pasta do projeto for 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 PropertyGroup elemento no arquivo .csproj :

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

    • SDK do .NET 7.0.200 e posterior

      Se você especificar a --output opção 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 --output opção não é permitida porque todas as saídas de todos os projetos construídos seriam copiadas para o diretório especificado, que não é compatível com projetos com vários destinos, bem como projetos que têm diferentes versões de dependências diretas e transitivas. Para obter mais informações, consulte A opção de nível --output de 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 --output opção. Por exemplo, dotnet publish -p:PublishDir=.\publish envia a saída de publicação de cada projeto para uma publish pasta na pasta que contém o arquivo de projeto.

    • SDK do .NET Core 2.x

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

      Se você especificar um caminho relativo ao publicar uma solução, a saída de cada projeto será para uma pasta separada relativa ao local do arquivo do projeto. Se você especificar um caminho absoluto ao publicar uma solução, toda a saída de publicação para todos os projetos irá para a pasta especificada.

  • --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 win-x64 máquina, especificar --os linux define o RID como linux-x64. Se você usar essa opção, não use a -r|--runtime opção. Disponível desde .NET 6.

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

    Publica 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. O padrão é true se um identificador de tempo de execução for especificado e o projeto for um projeto executável (não um projeto de biblioteca). Para obter mais informações, consulte Publicação de aplicativos .NET e Publicar aplicativos .NET com a CLI do .NET.

    Se essa opção for usada sem especificar true ou false, o padrão será true. Nesse caso, não coloque o argumento da solução ou do projeto imediatamente após --self-contained, porque true ou false é esperado nessa posição.

  • --no-self-contained

    Equivalente a --self-contained false.

  • --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 Publicação de aplicativos .NET e Publicar aplicativos .NET com a CLI do .NET. Se você usar esta opção, use --self-contained ou --no-self-contained também.

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

    Especifica se o registrador de terminal deve ser usado para a saída da 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 em log do terminal. off ignora a verificação de ambiente e usa o registrador de console padrão.

    O registrador de terminal 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.

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

    Define o RuntimeIdentifier para uma plataforma portátil RuntimeIdentifier com base na da sua máquina. Isso acontece implicitamente com propriedades que exigem um RuntimeIdentifier, como SelfContained, PublishAot, PublishSelfContained, PublishSingleFilee PublishReadyToRun. Se a propriedade estiver definida como false, essa resolução implícita não ocorrerá mais.

  • -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]. A predefinição é minimal. Para obter mais informações, veja LoggerVerbosity.

  • --version-suffix <VERSION_SUFFIX>

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

Exemplos

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

    dotnet publish

    Começando com o SDK do .NET Core 3.0, este exemplo também cria um executável dependente da estrutura para a plataforma atual.

  • Crie um executável autônomo 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 de 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

Consulte também