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>]
    [--sc|--self-contained [true|false]] [--no-self-contained]
    [-s|--source <SOURCE>] [--use-current-runtime, --ucr [true|false]]
    [-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 tempo de execução compartilhado esperado pelo aplicativo, 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 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, talvez o sistema de hospedagem não tenha o runtime compartilhado do .NET instalado. Para obter mais informações, consulte Publicar aplicativos .NET com a CLI do .NET.

Restauração implícita

Não é necessário executar dotnet restore, pois ele é executado implicitamente por todos os comandos que exigem uma restauração, como dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish e dotnet pack. Para desabilitar a restauração implícita, use a opção --no-restore.

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

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

MSBuild

O comando dotnet publish chama MSBuild, que invoca o destino Publish. Se a propriedade IsPublishable estiver definida para false em um projeto específico, o destino Publish não poderá ser invocado e o comando dotnet publish executará apenas a restauração dotnet implícita 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.

Além das próprias opções, o comando dotnet publish também aceita opções do MSBuild, como -p para configurar propriedades ou -l para 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 propriedade PublishProfile, eles serão ignorados. O 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 propriedade PublishProfileFullPath em vez da propriedade PublishProfile.

As seguintes propriedades do MSBuild 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 Cortar implantações e executáveis autocontidos. 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 saber mais, consulte Manifestos de publicidade.

Argumentos

  • PROJECT|SOLUTION

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

    • PROJECT é o caminho e o nome de arquivo de um arquivo de projeto C#, F# ou do Visual Basic ou o caminho para um diretório que contém um arquivo de projeto C#, F# ou do Visual Basic. Se o diretório não for especificado, ele usa como padrão 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 usa como padrão 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 computador win-x64, a especificação de --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 compilação 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 comando dotnet store. 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 elemento PropertyGroup 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 PublishDir msbuild 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.

    • 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 local do arquivo de projeto, e 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 (SO) 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 computador win-x64, a especificação de --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.

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

    Publica o runtime do .NET com seu aplicativo para que não seja necessário instalar o runtime 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 Publicação de aplicativos .NET e 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>

    A URI da origem do pacote NuGet a ser usada 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 Publicação de aplicativos .NET e 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.

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

    Define RuntimeIdentifier como uma plataforma portátil RuntimeIdentifier com base em um de seus computadores. Isso acontece implicitamente com propriedades que exigem RuntimeIdentifier, como SelfContained, PublishAot, PublishSelfContained, PublishSingleFile e PublishReadyToRun. Se a propriedade for definida como false, essa resolução implícita não ocorrerá mais.

  • --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 artigo 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 as referências P2P (projeto a projeto), apenas o projeto raiz durante a operação de restauração:

    dotnet publish --no-dependencies
    

Confira também