Compartilhar via

dotnet publish

Este artigo se aplica a: ✔️ SDK do .NET 6 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>|<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>] [-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 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, PC, Mac, laptop) para execução. É a única maneira oficialmente compatível 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 a visão geral da publicação de aplicativos .NET.

Restauração implícita

Você não precisa executar dotnet restore porque ela é executada implicitamente por todos os comandos que exigem que uma restauração ocorra, como dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishe 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 a restauração explícita faz sentido, como builds de integração contínua no do Azure DevOps Services ou em sistemas de build que precisam controlar explicitamente quando a restauração ocorre.

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

MSBuild

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

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

Se quiser que o cenário funcione em todos os locais, você poderá inicializar essas duas 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 de .pubxml são respeitadas apenas pelo Visual Studio e não têm efeito sobre . 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 dotnet/sdk#29817 planos para 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 de .pubxml de mais notáveis que não são compatíveis com são as seguintes que afetam o build:

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

Propriedades do MSBuild

As propriedades do 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 AOT (antecipada). 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 e não 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 essa propriedade é definida como true, a PublishSelfContained propriedade é definida implicitamente 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 usadas para reduzir o tamanho da implantação de um aplicativo ao publicar um executável autocontido. Para obter mais informações, consulte Cortar implantações autocontidas 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 esse comando for concluído, o download será interrompido. Para obter mais informações, consulte manifestos de publicidade.

Argumentos

PROJECT | SOLUTION | FILE

O projeto, a solução ou o arquivo C# (aplicativo baseado em arquivo) no qual operar. Se um arquivo não for especificado, o MSBuild pesquisa o diretório atual em busca de um projeto ou solução.

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

  • SOLUTION é o caminho e o nome do arquivo de um 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 ao .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 (.csproj) correspondente. Para obter mais informações, consulte Criar aplicativos C# baseados em arquivo.

Opções

  • -a|--arch <ARCHITECTURE>

    Especifica a arquitetura de destino. Essa é uma sintaxe abreviada para definir orid (identificador de runtime) , em que o valor fornecido é combinado com o RID padrão. Por exemplo, em um computador 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 Versão Prévia 7.

  • --artifacts-path <ARTIFACTS_DIR>

    Todos os arquivos de saída de build do comando executado serão executados em subpastas no caminho especificado, separados pelo projeto. Para obter mais informações, consulte de layout de saída de artefatos. Disponível desde o SDK do .NET 8.

  • -c|--configuration <CONFIGURATION>

    Define a configuração de build. Se você estiver desenvolvendo com o SDK do .NET 8 ou uma versão posterior, o comando usará a configuração de Release por padrão para projetos cujo TargetFramework está definido como net8.0 ou uma versão posterior. A configuração de build 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 de versão e 'dotnet pack' usa a configuração de versão.

  • --disable-build-servers

    Força o comando a ignorar todos os servidores de build persistentes. Essa opção fornece uma maneira consistente de desabilitar todo o uso do cache de build, o que força um build do zero. Um build 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. 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 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 cria o projeto antes da publicação. Ele também define implicitamente o sinalizador --no-restore.

  • --no-dependencies

    Ignora as referências projeto a projeto e restaura apenas 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, o padrão será [project_file_folder]/bin/[configuration]/[framework]/publish/ para binários executáveis e multiplataforma dependentes da estrutura. Ele usa como padrão [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ para um executável autocontido.

    Em um projeto 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 for myprojecte a pasta de saída de publicação for myproject/publishe 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 seja 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 não clara do caminho de saída. A opção --output não é permitida porque todas as saídas de todos os projetos criados seriam copiadas para o diretório especificado, que não é compatível com projetos multilocatários, bem como projetos que têm diferentes versões 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 ao build.

    • 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 pasta publish na pasta que contém o arquivo de projeto.

  • --os <OS>

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

  • --sc|--self-contained

    Publique o runtime do .NET com seu aplicativo para que o runtime não precise ser instalado no computador de destino. O padrão é true.

  • --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), consulte o catálogo RID. Para obter mais informações, consulte a visão geral da 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 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 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 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 atualmente aparecem na parte inferior do terminal. Cada projeto que está criando gera tanto o destino do MSBuild que está sendo construído no momento quanto o tempo gasto nesse destino. Você pode pesquisar essas informações para saber mais sobre o build. Quando um projeto é concluído, uma única seção "compilação concluída" é escrita que captura:

    • O nome do projeto compilado.
    • A estrutura de destino (se multilocatário).
    • O status desse build.
    • A saída primária desse build (que é hiperlink).
    • Qualquer diagnóstico gerado para esse projeto.

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

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

    Use o runtime atual como o runtime de destino.

  • -v|--verbosity <LEVEL>

    Define o nível de verbosidade 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 uma binária multiplataforma 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 da estrutura para a plataforma atual.

  • Crie um executável autossuficiente 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 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 runtime específico e uma 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 de projeto para projeto (P2P), 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 ao programa baseado em arquivo foi adicionado ao SDK do .NET 10.0.100.

Consulte também

  • Last updated on