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 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.
.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.
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.
Quando si imposta la proprietà obbligatoria e si esegue dotnet publish come illustrato nell'esempio seguente, l'app verrà distribuita usando AOT nativo.
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.
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:
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.
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.
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.
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.
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.
L'origine di questo contenuto è disponibile in GitHub, in cui è anche possibile creare ed esaminare i problemi e le richieste pull. Per ulteriori informazioni, vedere la guida per i collaboratori.
Feedback su .NET
.NET è un progetto di open source. Selezionare un collegamento per fornire feedback:
Creare app e servizi indipendenti distribuibili, altamente scalabili e resilienti usando la piattaforma .NET gratuita e open source. Con .NET è possibile usare la tecnologia di microservizi più diffusa, ad esempio Docker, Kubernetes, Dapr, Registro Azure Container e altro ancora per .NET e ASP.NET Servizi e applicazioni Core.
Progettare soluzioni end-to-end in Microsoft Azure per creare Funzioni di Azure, implementare e gestire app Web, sviluppare soluzioni che usano Archiviazione di Azure e altro ancora.