Compartilhar via

dotnet publish

  • Artigo

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

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>.

Arquivos .pubxml

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.

No arquivo .pubxml:

  • PublishUrl é usado pelo Visual Studio para indicar o destino de publicação.
  • PublishDir é usado pela CLI para indicar o destino de publicação.

Para que o cenário funcione em todos os locais, inicialize essas duas propriedades com o mesmo valor no arquivo .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 respeitadas apenas pelo Visual Studio e não têm efeito no dotnet publish. Estamos trabalhando para alinhar mais 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 aspecto de empacotamento da publicação e o dotnet/sdk#29817 planeja adicionar suporte para mais propriedades relacionadas a isso. Mas a CLI não faz o aspecto de automação de implantação da publicação, e as propriedades relacionadas a isso não têm suporte. As propriedades .pubxml mais notáveis que não têm suporte pelo dotnet publish são as seguintes que afetam o build:

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

propriedades MSBuild

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, confira 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.

  • --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 da compilação. Se você estiver desenvolvendo com o SDK do .NET 8 ou uma versão posterior, o comando usará 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 configuração de versão e 'dotnet pack' usa configuração de versão.

  • --disable-build-servers

    Força o comando a ignorar qualquer servidor de compilação persistente. Essa opção fornece uma maneira consistente de desativar 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 o SDK do .NET 7.

  • -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 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 criados serão copiadas para o diretório especificado, o que não é compatível com projetos multiplataforma, bem como projetos que têm diferentes versões de dependências diretas e transitivas. Para obter mais informações, confira A opção --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 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.

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

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

    O agente de terminal mostra a fase de restauração seguida pela fase de build. Durante cada fase, os projetos de construção atuais aparecem na parte inferior do terminal. Cada projeto que está sendo criado gera tanto o destino do MSBuild em construção no momento quanto o tempo gasto nesse destino. Você pode pesquisar essas informações para saber mais sobre o build. Quando a build de um projeto é concluída, é gravada uma única seção "build concluída" que captura:

    • O nome do projeto criado.
    • A estrutura de destino (se houver vários destinos).
    • O status dessa build.
    • A saída primária dessa build (que contém um hiperlink).
    • Qualquer diagnóstico gerado para esse projeto.

    Esta opção está disponível desde o .NET 8.

  • --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.

  • -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-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 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 net8.0 --runtime osx-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