dotnet publish

Este artigo se aplica 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>]
    [-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>]
    [--self-contained [true|false]] [--no-self-contained]
     [-s|--source <SOURCE>] [-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 de arquivos resultantes em um diretório. A saída inclui os seguintes ativos:

  • Código IL (Linguagem Intermediária) 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 runtime compartilhado que o aplicativo espera, bem como outras opções de configuração para o runtime (por exemplo, tipo de coleta de lixo).
  • As dependências do aplicativo, que são copiadas do cache 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, um computador, um Mac, um laptop) para execução. É a única maneira com suporte oficial de preparar o aplicativo para implantação. Dependendo do tipo de implantação especificado pelo projeto, o sistema de hospedagem pode ou não ter o runtime 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 é executado implicitamente por todos os comandos que exigem uma restauração, comodotnet new, , dotnet build, dotnet run, dotnet teste dotnet publishdotnet pack. Para desabilitar a restauração implícita, use a opção --no-restore .

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

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

MSBuild

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

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

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

Você também pode definir propriedades relacionadas à publicação referindo-se 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 examina a pasta Propriedades/PublishProfiles e pressupõe 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.

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

  • PublishReadyToRun

    Compila assemblies de aplicativo como formato ReadyToRun (R2R). R2R é uma forma de compilação antecipada (AOT). Para obter mais informações, consulte imagens ReadyToRun.

    Para ver avisos sobre dependências ausentes que podem causar falhas de runtime, 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 a publicação de arquivo único, consulte o documento de design de 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 usadas para reduzir o tamanho da implantação de um aplicativo ao publicar um executável independente. Para obter mais informações, consulte Trim auto-contained deployments and executables. 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 saber mais, consulte os recursos a seguir:

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 esse comando for concluído, o download será interrompido. Para obter mais informações, consulte manifestos de publicidade.

Argumentos

  • PROJECT|SOLUTION

    O projeto ou a solução a ser publicada.

    • PROJECTé o caminho e o nome do arquivo de um arquivo de projeto 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, ele será o padrão para o diretório atual.

    • SOLUTION é o caminho e o nome do arquivo de uma 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, ele será o padrão para o diretório atual.

Opções

  • -a|--arch <ARCHITECTURE>

    Especifica a arquitetura de destino. Essa é uma sintaxe abreviada para definir o RID (Identificador de Runtime), em que o valor fornecido é combinado com o RID padrão. Por exemplo, em um win-x64 computador, 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 a versão prévia 7 do .NET 6.

  • -c|--configuration <CONFIGURATION>

    Define a configuração da compilação. O padrão para a maioria dos projetos é Debug, mas você pode substituir as configurações de build em seu projeto.

  • -f|--framework <FRAMEWORK>

    Publica o aplicativo para a estrutura de destino especificada. Especifique a estrutura de destino no arquivo de projeto.

  • --force

    Forçará todas as dependências a serem resolvidas mesmo se última restauração tiver sido bem-sucedida. A especificação desse sinalizador é o mesmo que a exclusão do arquivo project.assets.json.

  • -?|-h|--help

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

  • --interactive

    Permite que o comando pare e aguarde 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 opção --manifest para cada manifesto.

  • --no-build

    Não compila o projeto antes da publicação. Também define o sinalizador --no-restore implicitamente.

  • --no-dependencies

    Ignora as referências projeto a projeto e só restaura o projeto raiz.

  • --nologo

    Não exibe a faixa de inicialização nem 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, ele usará o padrão [project_file_folder]/bin/[configuration]/[framework]/publish/ para um executável dependente de estrutura e binários multiplataforma. Ele usa o padrão [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ para um executável autossuficiente.

    Em um projeto Web, se a pasta de saída estiver na pasta do projeto, os 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 de publicação 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 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 para todos os projetos entrará na pasta especificada em relação ao diretório de trabalho atual. Para fazer a saída da publicação ir 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 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 de 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 entrará em uma pasta separada em relação ao local do arquivo de projeto. Se você especificar um caminho absoluto ao publicar uma solução, toda a saída de publicação para todos os projetos entrará na pasta especificada.

  • --os <OS>

    Especifica o sistema operacional de destino (SO). Essa é uma sintaxe abreviada para definir o RID (Identificador de Runtime), em que o valor fornecido é combinado com o RID padrão. Por exemplo, em um win-x64 computador, 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 o .NET 6.

  • --self-contained [true|false]

    Publica o runtime do .NET com seu aplicativo para que o runtime não precise ser instalado no computador de destino. O padrão é true se um identificador de runtime for especificado e o projeto for um projeto executável (não um projeto de biblioteca). Para obter mais informações, consulte a publicação de aplicativos .NET e a publicação de 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 runtime. Para obter uma lista de RIDs (Identificadores de Runtime), veja o Catálogo de RIDs. Para obter mais informações, consulte a publicação de aplicativos .NET e a publicação de aplicativos .NET com a CLI do .NET. Se você usar essa opção, use --self-contained ou --no-self-contained também.

  • -v|--verbosity <LEVEL>

    Define o nível de detalhes 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 da versão para substituir o asterisco (*) no campo de versão do arquivo de projeto.

Exemplos

  • Crie um binário multiplataforma dependente de 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 de estrutura para a plataforma atual.

  • Crie um executável autocontido para o projeto no diretório atual para um runtime específico:

    dotnet publish --runtime osx.10.11-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.10.11-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 uma estrutura de runtime e destino específica:

    dotnet publish --framework netcoreapp3.1 --runtime osx.10.11-x64
    
  • Publicar o arquivo de projeto especificado:

    dotnet publish ~/projects/app1/app1.csproj
    
  • Publique o aplicativo atual, mas não restaure referências de projeto para projeto (P2P), apenas o projeto raiz durante a operação de restauração:

    dotnet publish --no-dependencies
    

Veja também