'dotnet pack' utilise la configuration Release
La commande dotnet pack
, qui intègre du code dans un package NuGet, utilise désormais la configuration Release
au lieu de la configuration Debug
par défaut.
Comportement précédent
Précédemment, dotnet pack
utilisait la configuration Debug
, sauf si la configuration était spécifiée explicitement ou si PackRelease
était défini sur true
.
La propriété PackRelease
a été ajoutée dans .NET 7 pour accompagner ce changement cassant. Auparavant, vous pouviez définir la variable d’environnement DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS
pour utiliser PackRelease
dans un projet qui faisait partie d’une solution Visual Studio.
Nouveau comportement
Si vous développez avec le SDK .NET 8 ou une version ultérieure, dotnet pack
utilise la configuration Release
par défaut pour tous les projets. Si vous avez un script CI/CD, des tests ou du code dans lequel vous avez codé Debug
en dur dans un chemin de sortie, cette modification peut interrompre votre workflow. En outre, vous ne pourrez pas déboguer une application empaquetée, sauf si la configuration Debug
a été spécifiée explicitement (par exemple, à l’aide de dotnet pack --configuration Debug
.
dotnet pack
peut empaqueter pour plusieurs monikers d’infrastructure cible (TFM) en même temps. Si votre projet cible plusieurs versions et que vous avez des valeurs PackRelease
différentes pour différentes cibles, vous pouvez avoir un conflit où certains TFM empaquettent la configuration Release
et d’autres la configuration Debug
.
Pour les projets dans une solution :
dotnet pack
peut empaqueter tous les projets dans une solution Visual Studio si un fichier solution est fourni. Pour chaque projet de la solution, la valeur dePackRelease
est implicitement définie surtrue
si elle n’est pas définie. Pour quedotnet pack
détermine la configuration appropriée à utiliser, tous les projets de la solution doivent accepter leur valeur dePackRelease
.Cette modification peut entraîner une régression des performances de
dotnet pack
, en particulier pour les solutions qui contiennent de nombreux projets. Pour résoudre ce problème, une nouvelle variable d’environnementDOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS
a été introduite.La variable d’environnement
DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS
n’est plus reconnue.
Version introduite
.NET 8 Préversion 1
Type de changement cassant
Cette modification peut affecter la compatibilité des sources et est également un changement de comportement.
Raison du changement
Dans la plupart des cas, lorsque vous créez un package, vous souhaitez que votre code soit optimisé et que le package reste plus petit en excluant les informations de débogage.
La variable d’environnement DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS
a été supprimée, car le comportement activé est désormais le comportement par défaut, et le contrôle granulaire n’est plus nécessaire.
Action recommandée
Pour désactiver entièrement le nouveau comportement, vous pouvez définir la variable d’environnement
DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE
surtrue
(ou toute autre valeur). Cette variable affecte à la foisdotnet publish
etdotnet pack
.Pour spécifier explicitement la configuration de
Debug
pour l’empaquetage, utilisez l’option-c
ou--configuration
avecdotnet pack
.Si votre pipeline CI/CD est interrompu en raison de chemins de sortie codés en dur, mettez à jour les chemins vers
Release
au lieu deDebug
, désactivez le nouveau comportement à l’aide de la variable d’environnementDOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE
ou spécifiez que la configurationDebug
doit être utilisée.Si vous empaquetez une solution et qu’elle est brisée, car un ou plusieurs projets définissent explicitement une valeur pour
PackRelease
, vous devez explicitement définirPackRelease
surfalse
dans chaque projet :<PropertyGroup> <PackRelease>false</PackRelease> </PropertyGroup>
Si vous empaquetez une solution et que les performances ont régressé, vous pouvez définir la variable d’environnement
DOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS
surtrue
(ou toute autre valeur) pour supprimer la régression. Si vous utilisez cette variable et qu’un projet définitPackRelease
, tous les projets doivent définir cette valeur, ou vous pouvez utiliser un fichier Directory.Build.Props. Cette variable affecte à la foisdotnet publish
etdotnet pack
.