Compartilhar via


pacote dotnet

Este artigo se aplica a: ✔️ SDK do .NET 6 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>]
  [--disable-build-servers] [--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, 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 src pasta dentro que contém os arquivos de origem.

As dependências do NuGet do projeto empacotado são adicionadas ao arquivo .nuspec, portanto, elas são resolvidas corretamente quando o pacote é instalado. Se o projeto empacotado 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 projeto a projeto.

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

Observação

Em alguns casos, o build implícito não pode ser executado. Isso pode ocorrer quando GeneratePackageOnBuild é definido, para evitar uma dependência cíclica entre destinos de build e de pacote. O build também poderá falhar se houver um arquivo bloqueado ou outro problema.

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

Observação

Projetos Web não são empacotáveis.

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.

Arguments

PROJECT | SOLUTION

O projeto ou solução a ser empacotada. É 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 pesquisa o diretório atual em busca de um projeto ou arquivo de solução.

Opções

  • --artifacts-path <ARTIFACTS_DIR>

    Todos os arquivos de saída de compilação do comando executado irão para subpastas no 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 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.

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

  • --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 origem 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 entrada ou ação do usuário. Por exemplo, para concluir a autenticação.

  • --no-build

    Não cria o projeto antes de empacotar. Também define o sinalizador --no-restore implicitamente.

  • --no-dependencies

    Ignora as referências projeto a 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 a faixa de inicialização nem a mensagem de direitos autorais.

  • -o|--output <OUTPUT_DIRECTORY>

    Coloca os pacotes internos 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 e foi corrigida em 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 que pode ser atendido no pacote. Para obter mais informações, consulte o blog do .NET: o .NET Framework 4.5.1 dá suporte a 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 VersionSuffix propriedade MSBuild. O efeito dessa propriedade na versão do pacote depende dos valores e das VersionVersionPrefix propriedades, conforme mostrado na tabela a seguir:

    Propriedades com valores Versão do pacote
    None 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 estiver 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 será --version-suffix ignorado.

  • -?|-h|--help

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

Exemplos

  • Empacote o projeto no diretório atual:

    dotnet pack
    
  • Empacote o app1 projeto:

    dotnet pack ~/projects/app1/project.csproj
    
  • Empacote o projeto no diretório atual e coloque os pacotes resultantes na nupkgs pasta:

    dotnet pack --output nupkgs
    
  • Empacote o projeto no diretório atual na nupkgs pasta e ignore a etapa de build:

    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 2.1.0 do pacote 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 runtime 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 NuspecFile, NuspecBasePathe NuspecProperties, confira os seguintes recursos: