Pacote Dotnet
Este artigo aplica-se a: ✔️ SDK do .NET Core 3.1 e versões posteriores
dotnet pack
- Empacota o código em um pacote NuGet.
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
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 umasrc
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.
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 publish
e 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.
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.
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.
--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 comonet8.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]
, ediag[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 dasVersion
propriedades eVersionPrefix
, conforme mostrado na tabela a seguir:Propriedades com valores Versão de pacote Nenhuma 1.0.0
Version
$(Version)
VersionPrefix
apenas$(VersionPrefix)
VersionSuffix
apenas1.0.0-$(VersionSuffix)
VersionPrefix
eVersionSuffix
$(VersionPrefix)-$(VersionSuffix)
Se você quiser usar
--version-suffix
, especifiqueVersionPrefix
e nãoVersion
no arquivo de projeto. Por exemplo, seVersionPrefix
é0.1.2
e você passa--version-suffix rc.1
paradotnet pack
, a versão do pacote será0.1.2-rc.1
.Se
Version
tiver um valor e você passar--version-suffix
paradotnet pack
, o valor especificado para--version-suffix
será ignorado.
Embale o projeto no diretório atual:
.NET CLIdotnet pack
Embale o
app1
projeto:.NET CLIdotnet pack ~/projects/app1/project.csproj
Embale o projeto no diretório atual e coloque os
nupkgs
pacotes resultantes na pasta:.NET CLIdotnet pack --output nupkgs
Empacote o projeto no diretório atual na
nupkgs
pasta e ignore a etapa de compilação:.NET CLIdotnet 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:.NET CLIdotnet pack --version-suffix "ci-1234"
Defina a versão do pacote como
2.1.0
com aPackageVersion
propriedade MSBuild:.NET CLIdotnet pack -p:PackageVersion=2.1.0
Empacote o projeto para uma estrutura de destino específica:
.NET CLIdotnet pack -p:TargetFrameworks=net45
Empacote o projeto e use um tempo de execução específico (Windows) para a operação de restauração:
.NET CLIdotnet pack --runtime win-x64
Empacote o projeto usando um arquivo .nuspec :
.NET CLIdotnet pack ~/projects/app1/project.csproj -p:NuspecFile=~/projects/app1/project.nuspec -p:NuspecBasePath=~/projects/app1/nuget
Para obter informações sobre como usar
NuspecFile
o ,NuspecBasePath
eNuspecProperties
, consulte os seguintes recursos:
Comentários do .NET
O .NET é um projeto código aberto. Selecione um link para fornecer comentários: