Partilhar via


'dotnet pack' usa a configuração Release

O dotnet pack comando, que empacota o código em um pacote NuGet, agora usa a Release configuração em vez da Debug configuração por padrão.

Comportamento anterior

Anteriormente, usava a Debug configuração, dotnet pack a menos que a configuração fosse especificada explicitamente ou PackRelease fosse definida como true.

A PackRelease propriedade foi adicionada no .NET 7 como um caminho a seguir para essa alteração de rutura. Anteriormente, você podia definir a DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS variável de ambiente para usar PackRelease em um projeto que fazia parte de uma solução do Visual Studio.

Novo comportamento

Se você estiver desenvolvendo com o SDK do .NET 8 ou uma versão posterior, dotnet pack usa a Release configuração por padrão para todos os projetos. Se você tiver um script de CI/CD, testes ou código em que tenha codificado Debug em um caminho de saída, essa alteração poderá interromper seu fluxo de trabalho. Além disso, você não poderá depurar um aplicativo compactado a menos que a Debug configuração tenha sido especificada explicitamente (por exemplo, usando dotnet pack --configuration Debug.

dotnet pack pode empacotar para vários monikers de estrutura de destino (TFM) ao mesmo tempo. Se o seu projeto se destina a várias versões e você tem valores diferentes PackRelease para destinos diferentes, você pode ter um conflito onde alguns TFMs empacotam a Release configuração e outros empacotam a Debug configuração.

Para projetos em uma solução:

  • dotnet pack pode empacotar todos os projetos em uma solução do Visual Studio se receber um arquivo de solução. Para cada projeto na solução, o valor de PackRelease é implicitamente definido como true se estiver indefinido. Para dotnet pack determinar a configuração correta a ser usada, todos os projetos na solução devem concordar com seu valor de PackRelease.

  • Essa alteração pode fazer com que o desempenho do regredi, dotnet pack especialmente para soluções que contêm muitos projetos. Para resolver este problema, foi introduzida uma nova variável DOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS de ambiente.

  • A DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS variável de ambiente não é mais reconhecida.

Versão introduzida

.NET 8 Visualização 1

Tipo de mudança de rutura

Essa alteração pode afetar a compatibilidade da fonte e também é uma mudança comportamental.

Razão para a alteração

Na maioria dos casos, ao criar um pacote, você deseja que seu código seja otimizado e pode manter o pacote menor excluindo informações de depuração.

A DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS variável de ambiente foi removida, pois o comportamento habilitado agora é o comportamento padrão e o controle granular não é mais necessário.

  • Para desativar totalmente o novo comportamento, você pode definir a variável de DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE ambiente como true (ou qualquer outro valor). Esta variável afeta ambos e dotnet publishdotnet pack.

  • Para especificar explicitamente a Debug configuração para embalagem, use a -c opção ou --configuration com dotnet pack.

  • Se o pipeline de CI/CD estiver quebrado devido a caminhos de saída codificados, atualize os caminhos para Release em vez de , desative o novo comportamento usando a DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE variável de Debugambiente ou especifique que a Debug configuração deve ser usada.

  • Se você estiver empacotando uma solução e ela estiver quebrada porque um ou mais projetos definem explicitamente um valor para PackRelease, você deve definir PackRelease explicitamente como false em cada projeto:

    <PropertyGroup>
      <PackRelease>false</PackRelease>
    </PropertyGroup>
    
  • Se você estiver empacotando uma solução e o desempenho tiver regredido, poderá definir a DOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS variável de ambiente como true (ou qualquer outro valor) para remover a regressão. Se você usar essa variável e qualquer projeto definir PackRelease, todos os projetos deverão defini-la ou você poderá usar um arquivo Directory.Build.Props . Esta variável afeta ambos e dotnet publishdotnet pack.

Consulte também