Dela via

"dotnet pack" använder Release-konfiguration

Kommandotdotnet pack, som packar kod i ett NuGet-paket, använder nu konfigurationen Release i stället för konfigurationen Debug som standard.

Tidigare beteende

dotnet pack Tidigare använde du konfigurationen Debug om inte konfigurationen uttryckligen angavs eller PackRelease var inställd på true.

EgenskapenPackRelease lades till i .NET 7 som ett steg framåt för denna kompatibilitetsbrytande ändring. Tidigare kunde du ange miljövariabeln DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS som ska användas PackRelease i ett projekt som ingick i en Visual Studio-lösning.

Nytt beteende

Om du utvecklar med .NET 8 SDK eller en senare version dotnet pack använder du konfigurationen Release som standard för alla projekt. Om du har ett CI/CD-skript, tester eller kod där du har hårdkodat Debug till en utdatasökväg kan den här ändringen bryta arbetsflödet. Dessutom kan du inte felsöka en packad app om inte konfigurationen uttryckligen Debug har angetts (till exempel med hjälp av dotnet pack --configuration Debug.

dotnet pack kan packa för flera mågramverksbeteckningar (TFM) samtidigt. Om projektet riktar sig mot flera versioner och du har olika PackRelease värden för olika mål kan du ha en konflikt där vissa TFM:er packar konfigurationen Release och andra packar konfigurationen Debug .

För projekt i en lösning:

  • dotnet pack kan packa alla projekt i en Visual Studio-lösning om de får en lösningsfil. För varje projekt i lösningen anges värdet PackRelease implicit till true om det är odefinierat. För att kunna dotnet pack fastställa rätt konfiguration som ska användas måste alla projekt i lösningen komma överens om värdet för PackRelease.

  • Den här ändringen kan leda till att resultatet för dotnet pack försämras, särskilt för lösningar som innehåller många projekt. För att åtgärda detta har en ny miljövariabel DOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS introducerats.

  • Miljövariabeln DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS känns inte längre igen.

Version lanserad

Förhandsversion 1 av .NET 8

Typ av brytande ändring

Den här ändringen kan påverka källkompatibiliteten och är också en beteendeförändring.

Orsak till ändring

I de flesta fall när du skapar ett paket vill du att koden ska optimeras och kan hålla paketet mindre genom att exkludera felsökningsinformation.

Miljövariabeln DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS togs bort eftersom det beteende som den aktiverade nu är standardbeteendet och den detaljerade kontrollen inte längre behövs.

  • Om du vill inaktivera det nya beteendet helt kan du ange DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE miljövariabeln till true (eller något annat värde). Den här variabeln påverkar både dotnet publish och dotnet pack.

  • Om du uttryckligen vill ange konfigurationen Debug för packning använder du -c alternativet eller --configuration med dotnet pack.

  • Om din CI/CD-pipeline bryts på grund av hårdkodade utdatasökvägar, uppdaterar du sökvägarna till Release i stället för Debug, inaktiverar det nya beteendet med hjälp av miljövariabeln DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE eller anger att konfigurationen Debug ska användas.

  • Om du packar en lösning och den är trasig eftersom ett eller flera projekt uttryckligen anger ett värde för PackRelease, bör du uttryckligen ange PackRelease till false i varje projekt:

    <PropertyGroup>
  <PackRelease>false</PackRelease>
</PropertyGroup>

  • Om du packar en lösning och prestandan har regresserats kan du ange DOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS miljövariabeln till true (eller något annat värde) för att ta bort regressionen. Om du använder den här variabeln och alla projekt definierar PackReleasemåste alla projekt definiera den, eller så kan du använda filen Directory.Build.Props . Den här variabeln påverkar både dotnet publish och dotnet pack.

Se även