'dotnet pack' usa la configurazione Release

  • Articolo

Il comandodotnet pack, che include il codice in un pacchetto NuGet, ora usa la configurazione Release anziché la configurazione Debug per impostazione predefinita.

Comportamento precedente

In precedenza, dotnet pack usava la configurazione Debug a meno che la configurazione non sia stata specificata in modo esplicito o PackRelease sia stata impostata su true.

La proprietà PackRelease è 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_PACK_RELEASE_FOR_SOLUTIONS per usare PackRelease 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 pack usa la configurazione di Release per impostazione predefinita per tutti i progetti. 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. Inoltre, non sarà possibile eseguire il debug di un'app compressa a meno che non sia stata specificata in modo esplicito la configurazione Debug, ad esempio usando dotnet pack --configuration Debug.

dotnet pack può eseguire il pacchetto per più moniker del framework di destinazione (TFM) contemporaneamente. Se il progetto è destinato a più versioni e si dispone di valori di PackRelease diversi per destinazioni diverse, è possibile che ci sia un conflitto in cui alcuni TFM comprimono la configurazione Release e altri comprimono la configurazione Debug.

Per i progetti in una soluzione:

  • dotnet pack può comprimere tutti i progetti in una soluzione di Visual Studio se viene fornito un file di soluzione. Per ogni progetto nella soluzione, il valore di PackRelease viene impostato in modo implicito su true se non è definito. Affinché dotnet pack possa determinare la configurazione corretta da usare, tutti i progetti nella soluzione devono accettare il valore di PackRelease.

  • Questa modifica può causare un regresso delle prestazioni di dotnet pack, in particolare per le soluzioni che contengono molti progetti. Per risolvere questo problema, è stata introdotta una nuova variabile DOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS di ambiente.

  • La variabile di ambiente DOTNET_CLI_ENABLE_PACK_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 crea un pacchetto, si vuole ottimizzare il codice e mantenere il pacchetto più piccolo escludendo le informazioni di debug.

La variabile di ambiente DOTNET_CLI_ENABLE_PACK_RELEASE_FOR_SOLUTIONS è stata rimossa perché il comportamento abilitato è ora il comportamento predefinito e il controllo granulare non è più necessario.

  • Per disabilitare completamente il nuovo comportamento, è possibile impostare la variabile di ambiente DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE su true (o su qualsiasi altro valore). Questa variabile influisce sia su dotnet publish che su dotnet pack.

  • Per specificare in modo esplicito la configurazione Debug per la compressione, usare l'opzione -c o --configuration con dotnet pack.

  • 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 ambiente DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE oppure specificare che deve essere usata la configurazione Debug.

  • Se si esegue il pacchetto di una soluzione ed è interrotta perché uno o più progetti imposta in modo esplicito un valore per PackRelease, è consigliabile impostare in modo esplicito PackRelease su false in ogni progetto:

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

  • Se si pubblica un pacchetto e le prestazioni sono regredite, è possibile impostare la variabile di ambiente DOTNET_CLI_LAZY_PUBLISH_AND_PACK_RELEASE_FOR_SOLUTIONS su true (o su qualsiasi altro valore) per rimuovere la regressione. Se si usa questa variabile e qualsiasi progetto definisce PackRelease, tutti i progetti devono definirlo oppure è possibile usare un file Directory.Build.Props. Questa variabile influisce sia su dotnet publish che su dotnet pack.

Vedi anche