'dotnet publish' utilise la configuration Release
La commande dotnet publish
utilise désormais la configuration Release
au lieu de Debug
par défaut si le framework cible est .NET 8 ou une version ultérieure.
Comportement précédent
Précédemment, dotnet publish
utilisait la configuration Debug
, sauf si la configuration était spécifiée explicitement ou si PublishRelease
était défini sur true
.
La propriété PublishRelease
a été ajoutée dans .NET 7 pour accompagner ce changement cassant. Auparavant, vous pouviez définir la variable d’environnement DOTNET_CLI_ENABLE_PUBLISH_RELEASE_FOR_SOLUTIONS
pour utiliser PublishRelease
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 publish
utilise la configuration Release
par défaut pour les projets dont la valeur TargetFramework
est définie sur net8.0
ou une version ultérieure. 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.
Si votre projet cible plusieurs versions, le nouveau comportement s’applique uniquement si vous spécifiez un framework cible de .NET 8 ou version ultérieure lorsque vous publiez (par exemple, à l’aide de dotnet publish -f net8.0
).
Pour les projets dans une solution :
dotnet publish
peut publier tous les projets dans une solution Visual Studio si un fichier solution est fourni. Pour les projets de solution qui ciblent .NET 8 ou version ultérieure, la valeur dePublishRelease
est implicitement définie surtrue
si elle n’est pas définie. Toutefois, pour quedotnet publish
détermine la configuration appropriée à utiliser pour la solution, tous les projets de la solution doivent accepter leur valeur dePublishRelease
. Si un projet plus ancien de la solution aPublishRelease
défini surfalse
, vous devez également définir explicitement la propriété surfalse
pour les nouveaux projets .NET 8+.Cette modification peut entraîner une régression des performances de
dotnet publish
, 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_PUBLISH_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 publiez, vous souhaitez optimiser votre code, et pouvez réduire la taille de l’application en excluant les informations de débogage. Les clients demandaient à ce que Release
soit la configuration par défaut pour publish
depuis longtemps. En outre, Visual Studio offre ce comportement depuis de nombreuses années.
La variable d’environnement DOTNET_CLI_ENABLE_PUBLISH_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 la publication, utilisez l’option-c
ou--configuration
avecdotnet publish
.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 publiez une solution et qu’elle est interrompue, vous pouvez définir explicitement
PublishRelease
surtrue
(oufalse
pour revenir au comportement précédent).<PropertyGroup> <PublishRelease>true</PublishRelease> </PropertyGroup>
Vous pouvez également spécifier la propriété dans un fichier Directory.Build.Props. Toutefois, si vous la définissez sur
false
dans ce fichier, vous devez toujours définir explicitement la propriété surfalse
dans les projets .NET 8+ de la solution. De même, si certains projets définissent explicitement une valeur différente de la valeur du fichier Directory.Build.Props, la publication échoue.Si vous publiez 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. Toutefois, si vous définissez cette variable et que votre solution contient un projet .NET 8+ et un projet qui cible .NET 7 ou une version antérieure, la publication échoue jusqu’à ce que tous les projets définissentPublishRelease
. Cette variable affecte à la foisdotnet publish
etdotnet pack
.