dotnet pack

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

Nome

dotnet pack – Empacota o código em um pacote NuGet.

Sinopse

dotnet pack [<PROJECT>|<SOLUTION>] [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>] [--force]
    [--include-source] [--include-symbols] [--interactive]
    [--no-build] [--no-dependencies] [--no-restore] [--nologo]
    [-o|--output <OUTPUT_DIRECTORY>] [--runtime <RUNTIME_IDENTIFIER>]
    [-s|--serviceable] [--tl:[auto|on|off]] [-v|--verbosity <LEVEL>]
    [--version-suffix <VERSION_SUFFIX>]

dotnet pack -h|--help

Descrição

O comando dotnet pack compila o projeto e cria pacotes NuGet. O resultado desse comando é um pacote NuGet (ou seja, um arquivo .nupkg).

Se quiser gerar um pacote que contenha os símbolos de depuração, você terá duas opções disponíveis:

• --include-symbols - ele cria o pacote de símbolos.
• --include-source - ele cria o pacote de símbolos com uma pasta src dentro com os arquivos de origem.

As dependências do NuGet do projeto empacotado são adicionadas ao arquivo .nuspec para que possam ser resolvidas apropriadamente quando o pacote for instalado. Se o projeto embalado tiver referências a outros projetos, os outros projetos não serão incluídos no pacote. No momento, você precisa ter um pacote por projeto se tiver dependências de projeto a projeto.

Por padrão, dotnet pack compila primeiro o projeto. Se você quiser evitar esse comportamento, passe a opção --no-build. Com frequência, essa opção é útil em cenários de build de CI (integração contínua) nos quais você sabe que o código foi compilado anteriormente.

Você pode fornecer as propriedades de MSBuild para o comando dotnet pack para o processo de empacotamento. Para obter mais informações, consulte Propriedades de destino do pacote NuGet e a Referência de linha de comando MSBuild. A seção Exemplos mostra como usar a opção -p do MSBuild para alguns cenários diferentes.

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.

Este comando é compatível com as opções dotnet restore quando passado no formato longo (por exemplo, --source). Opções de formato curto, como -s, não são compatíveis.

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 empacotado. É um caminho para um arquivo csproj, vbproj ou fsproj, ou para um arquivo de solução ou diretório. Se não for especificado, o comando pesquisará o diretório atual em busca de um arquivo de projeto ou de solução.

Opções

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

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

• --include-source

  Inclui os pacotes NuGet de símbolos de depuração, além dos pacotes NuGet normais no diretório de saída. Os arquivos de origem são incluídos na pasta src dentro do pacote de símbolos.

• --include-symbols

  Inclui os pacotes NuGet de símbolos de depuração, além dos pacotes NuGet normais no diretório de saída.

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

• --no-build

  Não compila o projeto antes do empacotamento. Também define o sinalizador --no-restore implicitamente.

• --no-dependencies

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

• --no-restore

  Não executa uma restauração implícita ao executar o comando.

• --nologo

  Não exibe a faixa de inicialização nem a mensagem de direitos autorais.

• -o|--output <OUTPUT_DIRECTORY>

  Coloca os pacotes compilados no diretório especificado.

  • SDK do .NET 7.0.200

    No SDK 7.0.200, se você especificar a opção --output ao executar esse comando em uma solução, a CLI emitirá um erro. Essa é uma regressão que foi corrigida no 7.0.201 e versões posteriores do SDK do .NET.

• --runtime <RUNTIME_IDENTIFIER>

  Especifica o runtime de destino para o qual restaurar os pacotes. Para obter uma lista de RIDs (Identificadores de Runtime), veja o Catálogo de RIDs.

• -s|--serviceable

  Define o sinalizador operacional no pacote. Para obter mais informações, consulte Blog do .NET: o .NET 4.5.1 oferece suporte às atualizações de Segurança da Microsoft para bibliotecas NuGet do .NET.

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

• -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]. Para obter mais informações, consulte LoggerVerbosity.

• --version-suffix <VERSION_SUFFIX>

  Define o valor da propriedade VersionSuffix do MSBuild no projeto. O efeito dessa propriedade na versão do pacote depende dos valores e das propriedades Version e VersionPrefix, conforme mostrado na tabela a seguir:

  Propriedades com valores	Versão do pacote
  Nenhum	1.0.0
  Version	$(Version)
  VersionPrefix somente	$(VersionPrefix)
  VersionSuffix somente	1.0.0-$(VersionSuffix)
  VersionPrefix e VersionSuffix	$(VersionPrefix)-$(VersionSuffix)

  Se você quiser usar --version-suffix, especifique VersionPrefix e não Version no arquivo de projeto. Por exemplo, se VersionPrefix for 0.1.2 e você passar --version-suffix rc.1 para dotnet pack, a versão do pacote será 0.1.2-rc.1.

  Se Version tiver um valor e você passar --version-suffix para dotnet pack, o valor especificado para --version-suffix será ignorado.

Exemplos

• Empacota o projeto no diretório atual:

  dotnet pack
  

• Empacote o projeto app1:

  dotnet pack ~/projects/app1/project.csproj
  

• Empacote o projeto no diretório atual e coloque os pacotes resultantes na pastanupkgs:

  dotnet pack --output nupkgs
  

• Empacote o projeto no diretório atual da pasta nupkgs e ignora a etapa de compilação:

  dotnet pack --no-build --output nupkgs
  

• Com o sufixo da versão do projeto configurado como <VersionSuffix>$(VersionSuffix)</VersionSuffix> no arquivo .csproj, empacote o projeto atual e atualize a versão do pacote resultante com o sufixo especificado:

  dotnet pack --version-suffix "ci-1234"
  

• Defina a versão do pacote como 2.1.0 com a propriedade MSBuild PackageVersion:

  dotnet pack -p:PackageVersion=2.1.0
  

• Empacote o projeto para uma determinada estrutura de destino:

  dotnet pack -p:TargetFrameworks=net45
  

• Empacote o projeto e use um tempo de execução específico (Windows) para a operação de restauração:

  dotnet pack --runtime win-x64
  

• Empacote o projeto usando um arquivo .nuspec:

  dotnet pack ~/projects/app1/project.csproj -p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget
  

  Para obter mais informações sobre como usar NuspecFile, NuspecBasePath e NuspecProperties, consulte estes recursos:

  • Empacotamento usando um .nuspec
  • Pontos de extensão avançados para criar um pacote personalizado
  • Propriedades globais