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, dotnet pack usava a configuração Debug a menos que a configuração fosse explicitamente especificada ou PackRelease fosse definido para true.

A PackRelease propriedade foi adicionada no .NET 7 como uma solução para essa alteração disruptiva. 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 identificadores de frameworks alvo (TFM) ao mesmo tempo. Se o seu projeto se destina a múltiplas versões e possui valores diferentes de PackRelease para diferentes destinos, pode ocorrer um conflito onde alguns TFMs empacotam a configuração de Release enquanto outros empacotam a configuração de Debug.

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 de dotnet pack regredir, 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 disruptiva

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

Motivo da mudança

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 dotnet publish e dotnet pack.

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

  • Se o pipeline de CI/CD estiver quebrado devido a caminhos de saída hardcoded, atualize os caminhos para Release em vez de Debug, desative o novo comportamento usando a variável de ambiente DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE ou especifique que a configuração Debug 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 dotnet publish e dotnet pack.

Ver também

  • Last updated on