dotnet pack
Este artigo se aplica 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 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 pastasrc
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.
Observação
Em alguns casos, a compilação implícita não pode ser executada. Isso pode ocorrer quando GeneratePackageOnBuild
está definido, para evitar uma dependência cíclica entre destinos de compilação e pacote. A compilação também pode falhar se houver um arquivo bloqueado ou outro problema.
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.
Observação
Os projetos Web não são empacotáveis.
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.
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.
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.
--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 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 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]
ediag[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 propriedadesVersion
eVersionPrefix
, conforme mostrado na tabela a seguir:Propriedades com valores Versão do pacote Nenhum 1.0.0
Version
$(Version)
VersionPrefix
somente$(VersionPrefix)
VersionSuffix
somente1.0.0-$(VersionSuffix)
VersionPrefix
eVersionSuffix
$(VersionPrefix)-$(VersionSuffix)
Se você quiser usar
--version-suffix
, especifiqueVersionPrefix
e nãoVersion
no arquivo de projeto. Por exemplo, seVersionPrefix
for0.1.2
e você passar--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.
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 pasta
nupkgs
: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 MSBuildPackageVersion
: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
eNuspecProperties
, consulte estes recursos:
Comentários do .NET
O .NET é um projeto código aberto. Selecione um link para fornecer comentários: