Pacote Dotnet

Artigo
04/06/2024

Este artigo aplica-se 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

Description

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

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

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

As dependências do NuGet do projeto compactado são adicionadas ao arquivo .nuspec , para que sejam resolvidas corretamente quando o pacote for instalado. Se o projeto compactado tiver referências a outros projetos, os outros projetos não serão incluídos no pacote. Atualmente, você deve ter um pacote por projeto se tiver dependências de projeto para projeto.

Por padrão, dotnet pack cria o projeto primeiro. Se você deseja evitar esse comportamento, passe a --no-build opção. Essa opção geralmente é útil em cenários de compilação de Integração Contínua (CI) onde você sabe que o código foi criado anteriormente.

Nota

Em alguns casos, a compilação implícita não pode ser executada. Isso pode ocorrer quando GeneratePackageOnBuild é definido, para evitar uma dependência cíclica entre os destinos de compilação e pacote. A compilação também pode falhar se houver um arquivo bloqueado ou outro problema.

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

Nota

Os projetos da Web não podem ser empacotados.

Restauração implícita

Você não precisa executar dotnet restore porque ele é executado implicitamente por todos os comandos que exigem uma restauração para ocorrer, como dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishe dotnet pack. Para desativar a restauração implícita, use a --no-restore opção.

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

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

Este comando suporta as dotnet restore opções quando passado na forma longa (por exemplo, --source). Opções de formulário curto, como -s, não são suportadas.

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 este comando terminar, o download será interrompido. Para obter mais informações, consulte Manifestos de publicidade.

Argumentos

PROJECT | SOLUTION

O projeto ou solução a ser empacotado. É um caminho para um arquivo csproj, vbproj ou fsproj ou para um arquivo ou diretório de solução. Se não for especificado, o comando procura um arquivo de projeto ou solução no diretório atual.

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

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

-?|-h|--help

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

--include-source

Inclui os símbolos de depuração pacotes NuGet, além dos pacotes NuGet regulares no diretório de saída. Os arquivos de código-fonte são incluídos na src pasta dentro do pacote de símbolos.
--include-symbols

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

--interactive

Permite que o comando pare e aguarde a 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 cria o projeto antes de empacotar. Também coloca implicitamente a --no-restore bandeira.
--no-dependencies

Ignora referências de projeto para projeto e restaura apenas o projeto raiz.
--no-restore

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

Não exibe o banner de inicialização ou 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 --output opção ao executar esse comando em uma solução, a CLI emitirá um erro. Esta é uma regressão e foi corrigida na 7.0.201 e versões posteriores do SDK do .NET.
--runtime <RUNTIME_IDENTIFIER>

Especifica o tempo de execução de destino para o qual restaurar pacotes. Para obter uma lista de identificadores de tempo de execução (RIDs), consulte o catálogo RID.
-s|--serviceable

Define o sinalizador de manutenção no pacote. Para obter mais informações, consulte Blog do .NET: O .NET Framework 4.5.1 oferece suporte a atualizações de segurança da Microsoft para bibliotecas NuGet do .NET.

--tl:[auto|on|off]

Especifica se o registrador de terminal deve ser usado para a saída da compilação. 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 ativar o novo registrador. on ignora a verificação do ambiente e habilita o registro em log do terminal. off ignora a verificação de ambiente e usa o registrador de console padrão.

O registrador de terminal mostra a fase de restauração seguida pela fase de compilação. Durante cada fase, os projetos atualmente em construção aparecem na parte inferior do terminal. Cada projeto que está construindo produz tanto a meta do MSBuild que está sendo criada quanto a quantidade de tempo gasto nessa meta. Você pode pesquisar essas informações para saber mais sobre a compilação. Quando um projeto termina de construir, uma única seção "construção concluída" é escrita que captura:
- O nome do projeto construído.
- A estrutura de destino (se multidirecionada).
- O status dessa compilação.
- A saída primária dessa compilação (que é hiperligada).
- Qualquer diagnóstico gerado para esse projeto.
Esta opção está disponível a partir do .NET 8.

-v|--verbosity <LEVEL>

Define o nível de detalhamento do comando. Os valores permitidos são q[uiet], m[inimal], n[ormal], d[etailed], e diag[nostic]. Para obter mais informações, veja LoggerVerbosity.

--version-suffix <VERSION_SUFFIX>

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

Propriedades com valores	Versão de pacote
Nenhuma	`1.0.0`
`Version`	`$(Version)`
`VersionPrefix` apenas	`$(VersionPrefix)`
`VersionSuffix` apenas	`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 é 0.1.2 e você passa --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

Embale o projeto no diretório atual:
```
dotnet pack
```

Embale o app1 projeto:

dotnet pack ~/projects/app1/project.csproj

Embale o projeto no diretório atual e coloque os nupkgs pacotes resultantes na pasta:
```
dotnet pack --output nupkgs
```
Empacote o projeto no diretório atual na nupkgs pasta e ignore a etapa de compilação:
```
dotnet pack --no-build --output nupkgs
```
Com o sufixo de 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 fornecido:
```
dotnet pack --version-suffix "ci-1234"
```
Defina a versão do pacote como 2.1.0 com a PackageVersion propriedade MSBuild:
```
dotnet pack -p:PackageVersion=2.1.0
```
Empacote o projeto para uma estrutura de destino específica:
```
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 informações sobre como usar NuspecFileo , NuspecBasePathe NuspecProperties, consulte os seguintes recursos:

Partilhar via