Novità dell'SDK e degli strumenti per .NET 8

Questo articolo descrive le nuove funzionalità di .NET SDK e gli strumenti per .NET 8.

SDK

Questa sezione contiene le sottosezioni seguenti:

• Valutazione del progetto basata sull'interfaccia della riga di comando
• Output della compilazione del terminale
• Percorsi di output semplificati
• Comando 'dotnet workload clean'
• Asset 'dotnet publish' e 'dotnet pack'
• Motore di modelli
• Collegamento a un'origine
• SDK source-build

Valutazione del progetto basata sull'interfaccia della riga di comando

MSBuild include una nuova funzionalità che semplifica l'incorporamento dei dati di MSBuild in script o strumenti. I nuovi flag seguenti sono disponibili per i comandi dell'interfaccia della riga di comando, ad esempio dotnet publish, per ottenere i dati da usare nelle pipeline CI e altrove.

Flag	Descrizione
--getProperty:<PROPERTYNAME>	Recupera la proprietà MSBuild con il nome specificato.
--getItem:<ITEMTYPE>	Recupera gli elementi MSBuild del tipo specificato.
--getTargetResults:<TARGETNAME>	Recupera gli output dall'esecuzione della destinazione specificata.

I valori vengono scritti nell'output standard. Più valori o valori complessi vengono restituiti come JSON, come illustrato negli esempi seguenti.

>dotnet publish --getProperty:OutputPath
bin\Release\net8.0\

>dotnet publish -p PublishProfile=DefaultContainer --getProperty:GeneratedContainerDigest --getProperty:GeneratedContainerConfiguration
{
  "Properties": {
    "GeneratedContainerDigest": "sha256:ef880a503bbabcb84bbb6a1aa9b41b36dc1ba08352e7cd91c0993646675174c4",
    "GeneratedContainerConfiguration": "{\u0022config\u0022:{\u0022ExposedPorts\u0022:{\u00228080/tcp\u0022:{}},\u0022Labels\u0022...}}"
  }
}

>dotnet publish -p PublishProfile=DefaultContainer --getItem:ContainerImageTags
{
  "Items": {
    "ContainerImageTags": [
      {
        "Identity": "latest",
        ...
    ]
  }
}

Output della compilazione del terminale

dotnet build include una nuova opzione per produrre un output di compilazione più modernizzato. Questo output del logger del terminale raggruppa gli errori con il progetto da cui provengono, differenzia meglio i diversi framework di destinazione per i progetti con più destinazioni e fornisce informazioni in tempo reale sulle operazioni di compilazione. Per acconsentire esplicitamente al nuovo output, usare l'opzione --tl. Per altre informazioni su questa opzione, vedere le opzioni di dotnet build.

Percorsi di output semplificati

.NET 8 introduce un'opzione per semplificare il percorso di output e la struttura di cartelle per gli output di compilazione. In precedenza, le app .NET generavano un set articolato e complesso di percorsi di output per i diversi artefatti della compilazione. La nuova struttura del percorso di output semplificata raccoglie tutti gli output di compilazione in una posizione comune, rendendo così più efficiente l'individuazione per gli strumenti.

Per altre informazioni, vedere Layout di output degli artefatti.

dotnet workload clean comando

.NET 8 introduce un nuovo comando per pulire i pacchetti di carichi di lavoro che potrebbero rimanere a seguito di vari aggiornamenti di .NET SDK o Visual Studio. Se si verificano problemi durante la gestione dei carichi di lavoro, provare a usare workload clean per ripristinare in modo sicuro uno stato noto prima di riprovare. Il comando ha due modalità:

• dotnet workload clean

  Esegue il processo di Garbage Collection dei carichi di lavoro per carichi di lavoro basati su file o basati su MSI, pulendo i pacchetti orfani. I pacchetti orfani provengono da versioni disinstallate di .NET SDK o sono pacchetti per i quali i record di installazione per il pacchetto non esistono più.

  Se Visual Studio è installato, il comando elenca anche tutti i carichi di lavoro da pulire manualmente usando Visual Studio.

• dotnet workload clean --all

  Questa modalità è più aggressiva e pulisce ogni pacchetto nel computer con il tipo di installazione del carico di lavoro SDK corrente (e non da Visual Studio). Rimuove anche tutti i record di installazione dei carichi di lavoro per la banda di funzionalità .NET SDK in esecuzione e per quelle precedenti.

Asset dotnet publish e dotnet pack

Poiché i comandi dotnet publish e dotnet pack sono destinati a produrre asset di produzione, ora producono asset Release per impostazione predefinita.

L'output seguente illustra il diverso comportamento tra dotnet build e dotnet publishe come ripristinare la pubblicazione degli asset Debug impostando la proprietà PublishRelease su false.

/app# dotnet new console
/app# dotnet build
  app -> /app/bin/Debug/net8.0/app.dll
/app# dotnet publish
  app -> /app/bin/Release/net8.0/app.dll
  app -> /app/bin/Release/net8.0/publish/
/app# dotnet publish -p:PublishRelease=false
  app -> /app/bin/Debug/net8.0/app.dll
  app -> /app/bin/Debug/net8.0/publish/

Per altre informazioni, vedere'dotnet pack' usa la configurazione Release and 'dotnet publish' usa la configurazione Release.

Controllo di sicurezza dotnet restore

A partire da .NET 8, è possibile acconsentire esplicitamente ai controlli di sicurezza per individuare le vulnerabilità note quando vengono ripristinati i pacchetti di dipendenze. Questo controllo genera un report delle vulnerabilità di sicurezza con il nome del pacchetto interessato, la gravità della vulnerabilità e un collegamento all'avviso per altri dettagli. Quando si esegue dotnet add o dotnet restore, verranno visualizzati gli avvisi NU1901-NU1904 per eventuali vulnerabilità rilevate. Per altre informazioni, vedere Controllare la presenza di vulnerabilità di sicurezza.

Motore di modelli

Il motore di modelli offre un'esperienza più sicura in .NET 8 integrando alcune delle funzionalità correlate alla sicurezza di NuGet. I miglioramenti includono:

• Impedire il download dei pacchetti dai feed http:// per impostazione predefinita. Ad esempio, il comando seguente non riuscirà a installare il pacchetto del modello perché l'URL di origine non usa HTTPS.

  dotnet new install console --add-source "http://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json"

  È possibile ovviare a questa limitazione usando il flag --force.

• Per dotnet new, dotnet new install e dotnet new update, verificare la presenza di vulnerabilità note nel pacchetto del modello. Se vengono rilevate vulnerabilità e si desidera procedere, è necessario usare il flag --force.

• Per dotnet new, fornire informazioni sul proprietario del pacchetto del modello. La proprietà viene verificata dal portale NuGet e può essere considerata una caratteristica attendibile.

• Per dotnet search e dotnet uninstall, indicare se un modello è installato da un pacchetto "attendibile", ovvero che usa un prefisso riservato.

Collegamento all'origine

Source Link è ora incluso in .NET SDK. L'obiettivo è che includendo Source Link nell'SDK, invece di richiedere un <PackageReference> separato per il pacchetto, altri pacchetti includeranno queste informazioni per impostazione predefinita. Queste informazioni miglioreranno l'esperienza dell'IDE per gli sviluppatori.

Nota

Come effetto collaterale di questa modifica, le informazioni sul commit sono incluse nel valore InformationalVersion delle librerie e delle applicazioni compilate, anche quelle destinate a .NET 7 o a una versione precedente. Per altre informazioni, vedere Source Link incluso in .NET SDK.

SDK source-build

L'SDK (source-build) compilato per la distribuzione Linux include ora la possibilità di creare applicazioni autonome usando i pacchetti di runtime source-build. Il pacchetto di runtime specifico della distribuzione è incluso nell'SDK source-build. Durante la distribuzione autonoma si farà riferimento a questo pacchetto di runtime in bundle, abilitando così la funzionalità per gli utenti.

Supporto di AOT nativo

L'opzione per la pubblicazione come AOT nativo è stata introdotta per la prima volta in .NET 7. La pubblicazione di un'app con AOT nativo crea una versione completamente autonoma dell'app che non richiede un runtime. Tutto è incluso in un singolo file. .NET 8 offre i miglioramenti seguenti alla pubblicazione come AOT nativo:

• Aggiunta del supporto per le architetture x64 e Arm64 in macOS.

• Riduzione delle dimensioni delle app AOT nativo in Linux fino al 50%. La tabella seguente illustra le dimensioni di un'app "Hello World" pubblicata con AOT nativo che include l'intero runtime .NET in .NET 7 rispetto a .NET 8:

  Sistema operativo	.NET 7	.NET 8
  Linux x64 (con -p:StripSymbols=true)	3,76 MB	1,84 MB
  Windows x64	2,85 MB	1,77 MB

• Consente di specificare una preferenza di ottimizzazione: dimensioni o velocità. Per impostazione predefinita, il compilatore sceglie di generare codice veloce tenendo conto delle dimensioni dell'applicazione. Tuttavia, è possibile usare la proprietà MSBuild <OptimizationPreference> per ottimizzare in modo specifico per un aspetto o per l'altro. Per altre informazioni, vedere Ottimizzare le distribuzioni AOT.

Modello di app console

Il modello di app console predefinito include ora il supporto per AOT predefinito. Per creare un progetto configurato per la compilazione AOT, è sufficiente eseguire dotnet new console --aot. La configurazione del progetto aggiunta da --aot ha tre effetti:

• Genera un eseguibile indipendente nativo con AOT nativo quando si pubblica il progetto, ad esempio con dotnet publish o Visual Studio.
• Abilita gli analizzatori di compatibilità per trimming, AOT e singolo file. Questi analizzatori avvisano della presenza di eventuali parti potenzialmente problematiche del progetto.
• Abilita l'emulazione in fase di debug di AOT in modo che, quando si esegue il debug del progetto senza compilazione AOT, si ottiene un'esperienza simile ad AOT. Ad esempio, se si usa System.Reflection.Emit in un pacchetto NuGet senza annotazioni per AOT (e che pertanto non è stato rilevato dall'analizzatore di compatibilità), l'emulazione significa che non si avranno sorprese quando si tenta di pubblicare il progetto con AOT.

Sviluppare per piattaforme simili a iOS con AOT nativo

.NET 8 avvia il lavoro per abilitare il supporto AOT nativo per le piattaforme simili a iOS. È ora possibile compilare ed eseguire applicazioni .NET iOS e .NET MAUI con AOT nativo nelle piattaforme seguenti:

• ios
• iossimulator
• maccatalyst
• tvos
• tvossimulator

Dai test preliminari risulta che le dimensioni delle app su disco diminuiscono di circa il 35% per le app iOS .NET che usano AOT nativo anziché Mono. Le dimensioni delle app su disco per le app iOS .NET MAUI diminuiscono fino al 50%. Inoltre, anche il tempo di avvio è più veloce. Le app iOS .NET registrano un tempo di avvio più veloce di circa il 28%, mentre le prestazioni di avvio pe le app .NET MAUI iOS sono migliori di circa il 50% rispetto a Mono. Il supporto di .NET 8 è sperimentale e rappresenta solo un primo passo per il supporto di questa funzionalità nel suo complesso. Per altre informazioni, vedere il post di blog .NET 8 Performance Improvements in .NET MAUI (Miglioramenti delle prestazioni di .NET 8 in .NET MAUI).

Il supporto AOT nativo è disponibile come funzionalità che prevede il consenso esplicito destinata alla distribuzione di app; Mono è ancora il runtime predefinito per lo sviluppo e la distribuzione di app. Per compilare ed eseguire un'applicazione MAUI .NET con AOT nativo in un dispositivo iOS, usare dotnet workload install maui per installare il carico di lavoro .NET MAUI e dotnet new maui -n HelloMaui per creare l'app. Impostare quindi la proprietà MSBuild PublishAot su true nel file di progetto.

<PropertyGroup>
  <PublishAot>true</PublishAot>
</PropertyGroup>

Quando si imposta la proprietà obbligatoria e si esegue dotnet publish come illustrato nell'esempio seguente, l'app verrà distribuita usando AOT nativo.

dotnet publish -f net8.0-ios -c Release -r ios-arm64  /t:Run

Limiti

Non tutte le funzionalità di iOS sono compatibili con AOT nativo. Analogamente, non tutte le librerie comunemente usate in iOS sono compatibili con AOT nativo. Oltre alle limitazioni della distribuzione AOT nativo esistenti, l'elenco seguente mostra alcune delle altre limitazioni per le piattaforme simili a iOS:

• L'uso di AOT nativo è abilitato solo durante la distribuzione dell'app (dotnet publish).
• Il debug del codice gestito è supportato solo con Mono.
• La compatibilità con il framework MAUI .NET è limitata.

Compilazione AOT per le app Android

Per ridurre le dimensioni delle app, le app .NET e .NET MAUI destinate ad Android usano la modalità di compilazione AOT (Ahead Of Time) profilata quando vengono compilate in modalità Release. La compilazione AOT profilata influisce su un numero inferiore di metodi rispetto alla normale compilazione AOT. .NET 8 introduce la proprietà <AndroidStripILAfterAOT> che consente di acconsentire esplicitamente a un'ulteriore compilazione AOT per le app Android per ridurre ulteriormente le dimensioni delle app.

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
</PropertyGroup>

Per impostazione predefinita, l'impostazione di AndroidStripILAfterAOT su true sostituisce l'impostazione AndroidEnableProfiledAot predefinita, consentendo il trimming di (quasi) tutti i metodi compilati da AOT. È anche possibile usare la compilazione AOT profilata e la rimozione di IL insieme impostando in modo esplicito entrambe le proprietà su true:

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
  <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>

App di Windows compilate in piattaforme diverse

Quando si compilano app destinate a Windows in piattaforme non Windows, l'eseguibile risultante viene ora aggiornato con tutte le risorse Win32 specificate, ad esempio icona dell'applicazione, manifesto, informazioni sulla versione.

In precedenza, le applicazioni dovevano essere compilate in Windows per avere tali risorse. La correzione di questa lacuna nel supporto della compilazione incrociata è stata una richiesta popolare, trattandosi di un problema significativo con effetti sia sulla complessità dell'infrastruttura sia sull'utilizzo delle risorse.

.NET in Linux

Baseline di supporto minimo per Linux

Le baseline di supporto minimo per Linux sono state aggiornate per .NET 8. .NET è progettato per Ubuntu 16.04 per tutte le architetture. Questo aspetto è importante soprattutto per definire la versione minima di glibc per .NET 8. .NET 8 non verrà avviato nelle versioni di distribuzione che includono una versione di glibc precedente, ad esempio Ubuntu 14.04 o Red Hat Enterprise Linux 7.

Per altre informazioni, vedere le informazioni sul supporto della famiglia Red Hat Enterprise Linux.

Compilare .NET in Linux

Nelle versioni precedenti di .NET è possibile compilare .NET dall'origine, ma è necessario creare un "tarball di origine" dal commit del repository dotnet/installer corrispondente a una versione. In .NET 8 non è più necessario ed è possibile compilare .NET in Linux direttamente dal repository dotnet/dotnet. Questo repository usa dotnet/source-build per compilare runtime, strumenti e SDK .NET. Questa è la stessa compilazione usata da Red Hat e Canonical per compilare .NET.

La compilazione in un contenitore è l'approccio più semplice per la maggior parte delle persone, perché le immagini del contenitore dotnet-buildtools/prereqs contengono tutte le dipendenze necessarie. Per altre informazioni, vedere le istruzioni per la compilazione.

Verifica della firma NuGet

A partire da .NET 8, NuGet verifica i pacchetti firmati in Linux per impostazione predefinita. NuGet continua a verificare anche i pacchetti firmati in Windows.

La maggior parte degli utenti non dovrebbe notare la verifica. Tuttavia, se si dispone di un pacchetto di certificato radice esistente in /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem, è possibile che vengano visualizzati errori di attendibilità accompagnati dall'avviso NU3042.

È possibile rifiutare esplicitamente la verifica impostando la variabile di ambiente DOTNET_NUGET_SIGNATURE_VERIFICATION su false.

Analisi codice

.NET 8 include diversi nuovi analizzatori di codice e correzioni per verificare che le API della libreria .NET vengano usate in modo corretto ed efficiente. La tabella seguente riepiloga i nuovi analizzatori.

ID regola	Categoria	Descrizione
CA1856	Prestazioni	Viene generato quando l'attributo ConstantExpectedAttribute non viene applicato correttamente a un parametro.
CA1857	Prestazioni	Viene generato quando un parametro viene annotato con ConstantExpectedAttribute, ma l'argomento specificato non è una costante.
CA1858	Prestazioni	Per determinare se una stringa inizia con un prefisso specificato, è preferibile chiamare String.StartsWith piuttosto che chiamare String.IndexOf e quindi confrontare il risultato con zero.
CA1859	Prestazioni	Questa regola consiglia di aggiornare il tipo di variabili locali, campi, proprietà, parametri dei metodi e tipi restituiti dai metodi specifici da tipi interfaccia o astratti a tipi concreti, quando possibile. L'uso di tipi concreti porta a codice generato di qualità superiore.
CA1860	Prestazioni	Per determinare se un tipo di raccolta include elementi, è preferibile usare Length, Count o IsEmpty, piuttosto che chiamare Enumerable.Any.
CA1861	Prestazioni	Le matrici costanti passate come argomenti non vengono riutilizzate quando vengono chiamate ripetutamente, il che implica la creazione di una nuova matrice ogni volta. Per migliorare le prestazioni, valutare la possibilità di estrarre la matrice in un campo di sola lettura statico.
CA1865-CA1867	Prestazioni	L'overload char è un overload con prestazioni migliori per una stringa con un singolo carattere.
CA2021	Affidabilità	Enumerable.Cast<TResult>(IEnumerable) e Enumerable.OfType<TResult>(IEnumerable) richiedono tipi compatibili per funzionare correttamente. Le conversioni che supportano un maggior numero di dati e le conversioni definite dall'utente non sono supportate con i tipi generici.
CA1510-CA1513	Manutenibilità	Gli helper throw sono più semplici ed efficienti di un blocco if che costruisce una nuova istanza di eccezione. Questi quattro analizzatori sono stati creati per le eccezioni seguenti: ArgumentNullException, ArgumentException, ArgumentOutOfRangeException e ObjectDisposedException.

Diagnostica

Ricaricamento rapido C# supporta la modifica di elementi generici

A partire da .NET 8, Ricaricamento rapido C# supporta la modifica di tipi generici e metodi generici. Quando si esegue il debug di applicazioni console, desktop, per dispositivi mobili o WebAssembly con Visual Studio, è possibile applicare modifiche alle classi generiche e ai metodi generici nel codice C# o nelle pagine Razor. Per altre informazioni, vedere l'elenco completo delle modifiche supportate da Roslyn.

Vedi anche

• Novità di .NET 8