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

Questo articolo descrive le nuove funzionalità e i miglioramenti nell'SDK di .NET per .NET 11. L'ultimo aggiornamento è stato eseguito per l'anteprima 7. È possibile scaricare .NET 11 qui.

Dimensioni dell'SDK

Le dimensioni del programma di installazione di .NET SDK in Linux e macOS sono state ridotte deduplicando gli assembly usando collegamenti simbolici. I file duplicati .dll e .exe vengono identificati dall'hash del contenuto e sostituiti con collegamenti simbolici che puntano a una singola copia. Ciò influisce sui programmi di installazione tarball, .pkg, .debe .rpm .

L'analisi ha rilevato che 35% della directory SDK è costituito da file duplicati. In Linux x64, si tratta di 816 file totali di 140 MB su disco (53 MB compressi). Sostituendo i duplicati con collegamenti simbolici, l'archivio Linux x64 diminuisce significativamente nelle dimensioni:

Piattaforma Artefatto SDK .NET 10 dimensione (MB) .NET 11 Anteprima 2 (MB) Riduzione
linux-x64 Tarball 230 189 17.8%
linux-x64 deb 164 122 25.6%
linux-x64 Rpm 165 122 26.0%
linux-x64 contenitori Variabile Variabile 8-17%

L'SDK viene ulteriormente tagliato perché crossgen viene ignorato per gli assembly esistenti solo in DotnetTools/. Gli assembly che esistono anche all'esterno di DotnetTools/ vengono comunque sottoposti a crossgen: beneficiano del vantaggio in fase di avvio e il duplicato viene quindi rimosso, ma gli assembly esclusivi di DotnetTools/ rimangono solo IL. In una linux-x64 compilazione, in questo modo si riduce il tarball dell'SDK di 23,6 MB aggiuntivi.

La deduplicazione di Windows è pianificata per una futura anteprima.

Analisi del codice e avvisi

Miglioramenti dell'analizzatore del codice

CA1873: Riduzione del rumore e miglioramento dei messaggi

Sono stati apportati due miglioramenti a CA1873 (Evitare la registrazione dei log potenzialmente costosa):

Riduzione dei falsi positivi: Gli accessi alle proprietà, GetType(), GetHashCode()e GetTimestamp() non vengono più contrassegnati. La diagnostica ora si applica solo al livello di log Informazioni e al di sotto per impostazione predefinita, poiché i percorsi di avvisi, errori e di codice critico sono raramente percorsi frequentemente utilizzati.

Motivi specifici nei messaggi di diagnostica: Il messaggio di diagnostica include ora il motivo per cui è stato contrassegnato un argomento, consentendo di classificare in ordine di priorità gli avvisi da risolvere:

// Before
warning CA1873: Evaluation of this argument may be expensive and unnecessary if logging is disabled

// After
warning CA1873: Evaluation of this argument may be expensive and unnecessary if logging is disabled (method invocation)

I nove motivi specifici sono:

  • Invocazione del metodo
  • Creazione di oggetti
  • creazione di matrici
  • Conversione di boxing
  • Interpolazione di stringhe
  • Espressione di raccolta
  • Creazione di oggetti anonimi
  • Espressione Await
  • Con espressione

Correzioni di bug dell'analizzatore

Analyzer Correzione
CA1515 Correzione di falsi positivi quando sono presenti membri dell'estensione C#
CA1034 Correzione di falsi positivi quando sono presenti membri dell'estensione C#
CA1859 Correzione di una gestione non corretta delle implementazioni di interfaccia predefinite

AnalysisLevel corretto per .NET 11

I progetti con AnalysisLevel=latest usano in modo non corretto le regole dell'analizzatore di .NET 9 anziché le regole previste di .NET 11. Questo problema è stato risolto.

Nuovi avvisi dell'SDK

NETSDK1235: Custom .nuspec con PackAsTool

Viene generato un nuovo avviso quando un progetto imposta PackAsTool=true e specifica una proprietà personalizzata NuspecFile . I pacchetti di strumenti richiedono convenzioni specifiche di layout e di identificatore che in genere vengono violate dai file personalizzati .nuspec.

warning NETSDK1235: .NET Tools do not support using a custom .nuspec file, but the nuspec file 'custom.nuspec' was provided. Remove the NuspecFile property from this project to enable packing it as a .NET Tool.

L'operazione pack continua comunque con un avviso per evitare l'interruzione dei progetti esistenti.

Flusso di lavoro CLI e produttività degli sviluppatori

Supporto CLI del filtro di soluzione

dotnet sln ora può creare e modificare i filtri della soluzione (.slnf) direttamente dall'interfaccia della riga di comando. I filtri della soluzione consentono ai repository di grandi dimensioni di caricare o compilare un subset di progetti senza modificare la soluzione principale. Le operazioni supportate rispecchiano i comandi esistenti dotnet sln :

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj
dotnet sln MyApp.slnf list
dotnet sln MyApp.slnf remove src/Lib/Lib.csproj

Applicazioni basate su file distribuite tra i file

Le app basate su file supportano ora una #:include direttiva, quindi è possibile spostare gli helper condivisi in file separati senza rinunciare al flusso di lavoro basato su file:

#:include helpers.cs
#:include models/customer.cs

Console.WriteLine(Helpers.FormatOutput(new Customer()));

Passare variabili di ambiente con dotnet run

dotnet run -e KEY=VALUE passa le variabili di ambiente all'app avviata dalla riga di comando, senza che sia necessario esportare lo stato della shell o modificare i profili di avvio:

dotnet run -e ASPNETCORE_ENVIRONMENT=Development -e LOG_LEVEL=Debug

Le variabili di ambiente passate in questo modo sono disponibili per la logica DI MSBuild come RuntimeEnvironmentVariable elementi.

Miglioramenti di dotnet watch

.NET 11 aggiunge diversi miglioramenti dotnet watch per cicli di sviluppo locali a esecuzione prolungata:

  • Aspire integrazione:dotnet watch ora può integrarsi con gli host delle app Aspire, abilitando flussi di lavoro per il ricaricamento rapido nel modello di applicazione completo Aspire.
  • Ripristino da crash: Quando l'app si arresta in modo anomalo, dotnet watch lo riavvia automaticamente alla successiva modifica pertinente del file.
  • Windows supporto desktop: la gestione di CTRL+C è migliorata per le app desktop Windows, ad esempio Windows Forms e macchine virtuali Windows.

.NET 11 aggiunge anche la selezione dei dispositivi per i progetti MAUI e per dispositivi mobili. Dopo aver selezionato un framework di destinazione, dotnet watch chiama la destinazione MSBuild ComputeAvailableDevices, seleziona automaticamente quando è presente un solo dispositivo e mostra un selettore interattivo con funzione di ricerca quando sono presenti più dispositivi. Il dispositivo scelto viene passato a dotnet build e al sottoprocesso dotnet run avviato, inclusa una nuova esecuzione del ripristino se il dispositivo richiede un RuntimeIdentifier non presente nel ripristino originale.

Per pre-selezionare un dispositivo dalla riga di comando, usare:

dotnet watch --device <device-id>

Sono stati risolti i problemi di lunga durata dotnet watch seguenti:

  • La finestra di selezione del framework non sembra più bloccata perché due lettori chiamavano entrambi Console.ReadKey().
  • Ctrl+C e Ctrl+R non mostrano più uno spurio WebSocketException o ObjectDisposedException quando il trasporto WebSocket si interrompe.
  • Ricaricamento rapido non causa più deadlock su iOS quando UIKitSynchronizationContext è installato prima dell'esecuzione dell'hook di avvio.

Note

dotnet watch richiede <MtouchLink>None</MtouchLink> nel file .csproj per i progetti di iOS Simulator. Vedere dotnet/macios #25295.

Completamenti del guscio di pesce

Il provider della shell fish in precedenza emetteva un comando su una sola riga che delegava tutti i completamenti a una chiamata dinamica dotnet complete. Lo script generato ora analizza la riga di comando tokenizzata, genera completamenti statici per sottocomandi, opzioni e argomenti posizionali e ricorre alle chiamate dinamiche solo quando necessario. Corrisponde al comportamento dei provider Bash, Zsh e PowerShell.

dotnet reference torna alla directory corrente

dotnet reference add e dotnet reference remove ora ricorrono alla directory corrente quando non viene specificato alcun --project, in linea con il comportamento consolidato di dotnet reference list:

cd ClassLib2
dotnet reference add ../ClassLib1/ClassLib1.csproj   # now works without --project
dotnet reference remove ../ClassLib1/ClassLib1.csproj

In precedenza, questi comandi non riuscivano con Could not find project or directory '' quando vengono eseguiti da una directory che conteneva un file di progetto.

Supporto di 'dotnet reference' per le app basate su file

dotnet reference supporta ora le app basate su file. Usare dotnet reference add --file app.cs <project-path> per aggiungere #:project direttive direttamente all'app basata su file e usare dotnet reference list e dotnet reference remove per gestire tali riferimenti.

Avviso delle impostazioni di avvio spostato in stderr

Il messaggio informativo "Uso delle impostazioni di avvio da..." ora viene scritto in stderr anziché in stdout. Gli script che acquisisce l'output standard di dotnet run non devono più rimuovere questa riga.

Altri miglioramenti dell'interfaccia della riga di comando

  • dotnet format accetta --framework ora per i progetti con più destinazioni.
  • dotnet test in modalità MTP (Testing Platform) Microsoft supporta ora --artifacts-path.
  • dotnet tool exec e dnx non richiedono più un'approvazione aggiuntiva durante l'esecuzione di strumenti.
  • dotnet nuget <subcommand> --help ora reindirizza correttamente all'output della guida della CLI di NuGet anziché ricorrere alla guida generica.
  • dotnet publish non rimuove più le DLL native nelle esecuzioni successive della pubblicazione come file singolo.

Asset Web e dati di telemetria

Gruppi di asset per risorse Web statiche

Static Web Assets SDK aggiunge il supporto per i gruppi di asset, un modo per dichiarare gruppi di asset correlati che condividono metadati di pubblicazione, impronta digitale e endpoint. L'attività correlata DefineStaticWebAssetEndpoints acquisisce un parametro AdditionalEndpointDefinitions e il glob matcher espone lo stem catturato ** così da poter definire dichiarativamente endpoint aggiuntivi (ad esempio route di documento predefinito come / per **/index.html).

Si tratta dell'infrastruttura per gli autori di componenti ASP.NET Core e gli autori di estensioni SDK. La maggior parte degli sviluppatori di app ne vede il risultato indirettamente, poiché i pacchetti di componenti Razor e Blazor vengono distribuiti con metadati delle risorse statiche più puliti.

OpenTelemetry sostituisce Application Insights per i dati di telemetria dell'interfaccia della riga di comando

La CLI dotnet usa ora OpenTelemetry (OTel) con Monitoraggio di Azure e gli exporter OTLP per la telemetria facoltativa, sostituendo la precedente dipendenza Microsoft.ApplicationInsights. Il comportamento rivolto all'utente è invariato. Gli stessi dati di telemetria vengono raccolti con lo stesso rifiuto esplicito tramite DOTNET_CLI_TELEMETRY_OPTOUT. L'obiettivo è rendere la CLI compatibile con NativeAOT.

Architettura CLI

Punto di ingresso NativeAOT per dotnet CLI

Per abilitare l'avvio quasi immediato per le chiamate comuni dell'interfaccia della riga di comando, .NET 11 abilita ora l'host dell'interfaccia della riga di comando compilato dotnet da NativeAOT per impostazione predefinita. È possibile rifiutare esplicitamente impostando DOTNET_CLI_ENABLEAOT=false. I parser gestiti e NativeAOT condividono un'implementazione, quindi il percorso AOT analizza, convalida e esegue il --help rendering per ogni comando.

I comandi che possono essere eseguiti interamente senza il runtime gestito vengono eseguiti in modo nativo. Ogni altro comando ripiega in modo trasparente sulla CLI gestita. I comandi seguenti vengono gestiti completamente dal percorso AOT:

  • dotnet --version, dotnet --info, dotnet --help
  • dotnet <command> --help per ogni comando predefinito
  • dotnet --cli-schema
  • dotnet sln list, dotnet sln migrate, dotnet sln remove

Le invocazioni di strumenti e comandi esterni (strumenti globali, comandi PATH, comandi app-base) ora vengono risolte e avviate fuori processo anche dal percorso AOT, evitando l'avvio di 600-700 ms della CLI gestita per comandi come dotnet ef o dotnet dev-certs.

Gli span di tracciamento OpenTelemetry vengono emessi dal percorso AOT con corrette relazioni padre/figlio rispetto agli span CLI gestiti, consentendo l’analisi end-to-end delle tracce distribuite su entrambi gli host.

Server MSBuild abilitato per impostazione predefinita

Il server MSBuild è ora abilitato per impostazione predefinita. In questo modo si mantiene un ruolo di lavoro MSBuild frequente tra le chiamate dell'interfaccia della riga di comando, riducendo il sovraccarico di avvio per i comandi di compilazione e test ripetuti. Per rifiutare esplicitamente, impostare DOTNET_CLI_USE_MSBUILD_SERVER=false o MSBUILDUSESERVER=0.

Ready-to-Run parziale per gli strumenti dello stack superiore

Una nuova proprietà MSBuild consente agli strumenti di livello superiore (ad esempio, dotnet/macios e dotnet/maui) di dichiarare un elenco di assembly da compilare parzialmente con R2R ed escludere dall'immagine composita. Lo scenario alla base è la precompilazione del codice XAML generato nelle compilazioni di debug per velocizzare l'avvio con F5 senza sostenere l'intero costo di crossgen per il resto dell'applicazione. Gli sviluppatori di app non impostano direttamente questa proprietà: è un hook usato dai workload per dispositivi mobili nei relativi target.

Miglioramenti dei test

miglioramenti dei test dotnet

.NET 11 aggiunge diverse funzionalità durante dotnet test l'esecuzione tramite Microsoft Testing Platform (MTP):

  • --no-dependencies: Salta la creazione dei riferimenti tra progetti, in modo analogo al comportamento esistente di dotnet build --no-dependencies.
  • DOTNET_TEST_RUNNER variabile di ambiente: seleziona il test runner senza richiedere una global.json modifica. Impostarlo su VSTest o Microsoft.Testing.Platform per sovrascrivere global.json per la sessione corrente.
  • --use-current-runtime / --ucr: ha come destinazione il runtime corrente durante il ripristino e la compilazione, in linea con l'opzione già disponibile in dotnet build e dotnet publish.
  • --test-modules pattern di esclusione: i pattern che iniziano con ! vengono ora trattati come esclusioni e gli spazi tra i punti e virgola vengono rimossi, consentendo il corretto funzionamento delle espressioni CI in formato YAML folded.
  • Conteggi dei test per assembly: la riga di riepilogo per le esecuzioni di più assembly include ora conteggi per assembly.
  • Argomenti del logger del terminale: --tl, --terminalloggere --tlp vengono ora inoltrati a MSBuild anziché essere passati come argomenti dell'applicazione di test.
  • Visualizzazione in tempo reale dei test in corso: l'area di avanzamento mostra i test in esecuzione tramite un nuovo TestInProgressMessages evento IPC. Il pannello mantiene il taglio per assembly per esecuzioni parallele di grandi dimensioni ed è abilitato solo per i terminali ANSI interattivi.
  • Interruzione Ctrl+C in due fasi: alla prima pressione si interrompe la pianificazione di nuove applicazioni di test e viene visualizzato un messaggio informativo; alla seconda pressione vengono terminati forzatamente tutti i processi figli delle applicazioni di test.
  • --device per MAUI: selezionare un dispositivo per framework di destinazione durante l'esecuzione di test per i progetti .NET MAUI.
  • Inoltro dell'output in Protocol 1.1.0: quando l'host di test supporta il protocollo 1.1.0, stdout/stderr e i messaggi IOutputDevice vengono trasmessi in tempo reale tramite il reporter del terminale anziché essere visualizzati solo in caso di errore.

Opzioni dei criteri dotnet test a livello di esecuzione

dotnet testsupporta ora le opzioni e --maximum-failed-tests a livello --timeout di esecuzione in Microsoft modalità piattaforma di test. Queste opzioni consentono di arrestare esecuzioni lunghe o rumorose in modo coerente tra esecuzioni multiprogetto.

Supporto dei test dotnet per i progetti di attraversamento

dotnet test supporta Microsoft.Build.Traversal ora i progetti. L'SDK espande i grafici attraversati, deduplica i riferimenti ripetuti ed esegue test per il set di progetti aggregato.

Miglioramenti di dotnet test reporter e artefatti

La gestione dei report e degli artefatti è stata migliorata per le esecuzioni multimodulo, tra cui il rendering previsto e effettivo nell'output degli errori, la logica di verdetto zero-test di esecuzione intera e la post-elaborazione automatica degli artefatti di test compatibili.

I modelli di test supportano xUnit v3 e NUnit in Microsoft. Testing.Platform

Il modello predefinito xunit aggiunge un'opzione --xunit-version . Usare v3 per generare un progetto xUnit v3 che usa Microsoft.Testing.Platform come strumento di esecuzione predefinito:

dotnet new xunit --xunit-version v3
dotnet new xunit --xunit-version v3 --test-runner VSTest

Il modello nunit aggiunge analogamente un'opzione --test-runner per abilitare Microsoft.Testing.Platform:

dotnet new nunit --test-runner Microsoft.Testing.Platform

Entrambe le opzioni sono disponibili per i modelli C#, F# e VB.

Aggiornamenti dei contenitori e degli strumenti

Compilazione di container multiarchitettura con Podman

Il supporto integrato dell'SDK per la pubblicazione di contenitori ora consente di creare immagini di contenitori multiarchitettura quando si usa Podman come motore per contenitori. In precedenza, le compilazioni multi-arco richiedevano Docker. Questo sblocca i flussi di lavoro multi-arch senza radice nelle distribuzioni Linux che spediscono Podman per impostazione predefinita.

Selezione del runtime del contenitore locale nativo della piattaforma

La pubblicazione dei contenitori ora preferisce i runtime locali nativi della piattaforma quando disponibili: wslc in Windows e container in macOS. Docker e Podman rimangono fallback. Per forzare un runtime, impostare LocalRegistry in modo esplicito nel progetto o nel profilo di pubblicazione.

Gli output TypeScript si integrano con asset Web statici

I progetti che usano Microsoft.TypeScript.MSBuild nelle librerie di classi Razor ora integrano correttamente gli output di compilazione TypeScript con ASP.NET Core Asset Web statici. La nuova integrazione associa gli output TypeScript nella pipeline Static Web Assets dopo la compilazione, abilitando la compressione, l'impronta digitale e il corretto comportamento di ricompilazione. In precedenza, le operazioni di ricompilazione potevano non riuscire perché gli output di TypeScript venivano rilevati prima della compilazione o perché riferimenti obsoleti persistevano dopo la pulizia.

Server MSBuild e variabili di ambiente di OpenTelemetry

La CLI dotnet non disattiva più il server di compilazione MSBuild quando DOTNET_CLI_USE_MSBUILD_SERVER non è impostato. In precedenza l'interfaccia della riga di comando scriveva MSBUILDUSESERVER=0in modo incondizionato , ignorando qualsiasi valore impostato dall'utente. Ora, se DOTNET_CLI_USE_MSBUILD_SERVER non è impostato, la CLI lascia MSBUILDUSESERVER invariato così da poter abilitare direttamente il server MSBuild.

L’esportatore di telemetria OTLP è ora abilitato anche quando è presente una qualsiasi variabile di ambiente OpenTelemetry standard OTEL_EXPORTER_OTLP_* (endpoint, protocollo, header o timeout, incluse le varianti specifiche del segnale _TRACES_* e _METRICS_*), oltre all’esistente flag DOTNET_CLI_TELEMETRY_ENABLE_EXPORTER.

Includere DLL nelle app basate su file

Le app basate su file possono ora includere riferimenti DLL compilati usando #:include senza un flag di funzionalità. Il mapping dei tipi di elemento predefinito considera i .dll file come Reference elementi, quindi è possibile fare riferimento direttamente alle librerie predefinite:

#:include ./libs/MyLibrary.dll

MyLibrary.Helper.DoWork();

Inoltre, ora è consentito che un maggior numero di direttive #: sia presente in forma duplicata nei file inclusi quando i relativi valori corrispondono (#:sdk, #:property, #:package), consentendo così di avere file di libreria autonomi che dichiarano le proprie dipendenze senza generare conflitti quando vengono inclusi da più punti di ingresso.

Vedere anche

  • Last updated on