'dotnet publish' usa la configurazione Release
Il comando dotnet publish
usa ora la configurazione Release
anziché la configurazione Debug
per impostazione predefinita se il framework di destinazione è .NET 8 o versione successiva.
Comportamento precedente
In precedenza, dotnet publish
usava la configurazione Debug
a meno che la configurazione non sia stata specificata in modo esplicito o PublishRelease
sia stata impostata su true
.
La proprietà PublishRelease
è stata aggiunta in .NET 7 come percorso in avanti a questa modifica di rilievo. In precedenza, è possibile impostare la variabile di ambiente DOTNET_CLI_ENABLE_PUBLISH_RELEASE_FOR_SOLUTIONS
per usare PublishRelease
in un progetto che faceva parte di una soluzione di Visual Studio.
Nuovo comportamento
Se si sviluppa con .NET 8 SDK o una versione successiva, dotnet publish
usa la configurazione Release
per impostazione predefinita per i progetti i cui valori TargetFramework
sono impostati su net8.0
o versione successiva. Se si dispone di un codice, un test o uno script CI/CD in cui Debug
è stato hardcoded in un percorso di output, questa modifica può interrompere il flusso di lavoro.
Se il progetto è destinato a più versioni, il nuovo comportamento si applica solo se si specifica un framework di destinazione di .NET 8 o versione successiva quando si pubblica (ad esempio, usando dotnet publish -f net8.0
).
Per i progetti in una soluzione:
dotnet publish
può pubblicare tutti i progetti in una soluzione di Visual Studio se viene fornito un file di soluzione. Per i progetti di soluzione destinati a .NET 8 o versione successiva, il valore diPublishRelease
viene impostato in modo implicito sutrue
se non è definito. Tuttavia, affinchédotnet publish
possa determinare la configurazione corretta da usare per la soluzione, tutti i progetti nella soluzione devono concordare il relativo valore diPublishRelease
. Se un progetto precedente nella soluzione haPublishRelease
impostato sufalse
, è necessario impostare in modo esplicito la proprietà sufalse
per tutti i nuovi progetti .NET 8+.Questa modifica può causare un regresso delle prestazioni di
dotnet publish
, in particolare per le soluzioni che contengono molti progetti. Per risolvere questo problema, è stata introdotta una nuova variabileDOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS
di ambiente.La variabile di ambiente
DOTNET_CLI_ENABLE_PUBLISH_RELEASE_FOR_SOLUTIONS
non viene più riconosciuta.
Versione introdotta
.NET 8 anteprima 1
Tipo di modifica che causa un'interruzione
Questa modifica può influire sulla compatibilità delle origini ed è anche una modifica comportamentale.
Motivo della modifica
Nella maggior parte dei casi, quando si pubblica si vuole ottimizzare il codice e mantenere l'app più piccola escludendo le informazioni di debug. I clienti chiedono da tempo che Release
sia la configurazione predefinita per publish
. Anche Visual Studio ha avuto questo comportamento per molti anni.
La variabile di ambiente DOTNET_CLI_ENABLE_PUBLISH_RELEASE_FOR_SOLUTIONS
è stata rimossa perché il comportamento abilitato è ora il comportamento predefinito e il controllo granulare non è più necessario.
Azione consigliata
Per disabilitare completamente il nuovo comportamento, è possibile impostare la variabile di ambiente
DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE
sutrue
(o su qualsiasi altro valore). Questa variabile influisce sia sudotnet publish
che sudotnet pack
.Per specificare in modo esplicito la configurazione
Debug
per la pubblicazione, usare l'opzione-c
o--configuration
condotnet publish
.Se la pipeline CI/CD è interrotta a causa di percorsi di output hardcoded, aggiornare i percorsi in
Release
anzichéDebug
, disabilitare il nuovo comportamento usando la variabile di ambienteDOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE
oppure specificare che deve essere usata la configurazioneDebug
.Se si pubblica una soluzione ed è interrotta, è possibile impostare
PublishRelease
sutrue
in modo esplicito (ofalse
per ripristinare il comportamento precedente).<PropertyGroup> <PublishRelease>true</PublishRelease> </PropertyGroup>
In alternativa, è possibile specificare la proprietà in un file Directory.Build.Props. Tuttavia, se la si imposta
false
in questo file, sarà comunque necessario impostare in modo esplicito la proprietà sufalse
nei progetti .NET 8+ nella soluzione. Analogamente, se alcuni progetti impostano in modo esplicito un valore diverso dal valore nel file Directory.Build.Props, la pubblicazione avrà esito negativo.Se si pubblica una soluzione e le prestazioni sono regredite, è possibile impostare la variabile di ambiente
DOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS
sutrue
(o su qualsiasi altro valore) per rimuovere la regressione. Tuttavia, se si imposta questa variabile e la soluzione contiene un progetto .NET 8+ e un progetto destinato a .NET 7 o versioni precedenti, la pubblicazione avrà esito negativo finché tutti i progetti non definisconoPublishRelease
. Questa variabile influisce sia sudotnet publish
che sudotnet pack
.