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

Questo articolo descrive nuove funzionalità e miglioramenti in .NET SDK per .NET 10.

Miglioramenti degli strumenti .NET

Strumenti .NET specifici della piattaforma

Gli strumenti .NET possono ora essere pubblicati con il supporto per più RuntimeIdentifiers (RID) in un singolo pacchetto. Gli autori di strumenti possono aggregare file binari per tutte le piattaforme supportate e l'interfaccia della riga di comando di .NET selezionerà quella corretta in fase di installazione o runtime. Questo rende molto più semplice la creazione e la distribuzione di strumenti multipiattaforma.

Questi strumenti avanzati supportano varie varianti di creazione di pacchetti:

• Indipendente dal framework, indipendente dalla piattaforma (modalità classica, viene eseguito ovunque con .NET 10 installato)
• Dipendente dal framework, specifico della piattaforma (più piccolo, ottimizzato per ogni piattaforma)
• Indipendente, specifico della piattaforma (include il runtime, nessuna installazione .NET necessaria)
• Ritagliato, specifico della piattaforma (più piccolo, taglia il codice inutilizzato)
• Compilato AOT, specifico per la piattaforma (massime prestazioni e minime dimensioni di distribuzione)

Questi nuovi strumenti funzionano in modo molto simile alle normali applicazioni pubblicate, quindi tutte le opzioni di pubblicazione che è possibile usare con le applicazioni (ad esempio, indipendenti, tagliate o AOT) possono essere applicate anche agli strumenti.

Esecuzione di uno strumento one-shot

È ora possibile usare il dotnet tool exec comando per eseguire uno strumento .NET senza installarlo a livello globale o locale. Ciò è particolarmente prezioso per CI/CD o l'uso effimero.

dotnet tool exec --source ./artifacts/package/ dotnetsay  "Hello, World!"
Tool package dotnetsay@1.0.0 will be downloaded from source <source>.
Proceed? [y/n] (y): y
  _   _          _   _                __        __                 _       _   _
 | | | |   ___  | | | |   ___         \ \      / /   ___    _ __  | |   __| | | |
 | |_| |  / _ \ | | | |  / _ \         \ \ /\ / /   / _ \  | '__| | |  / _` | | |
 |  _  | |  __/ | | | | | (_) |  _      \ V  V /   | (_) | | |    | | | (_| | |_|
 |_| |_|  \___| |_| |_|  \___/  ( )      \_/\_/     \___/  |_|    |_|  \__,_| (_)
                                |/

Verrà scaricato ed eseguito il pacchetto dello strumento specificato in un unico comando. Per impostazione predefinita, agli utenti viene richiesto di confermare il download se lo strumento non esiste già in locale. La versione più recente del pacchetto dello strumento scelto viene usata a meno che non venga specificata una versione esplicita , ad esempio dotnetsay@0.1.0.

L'esecuzione singola di uno strumento funziona perfettamente con i manifesti degli strumenti locali. Se si esegue uno strumento da una posizione contenente una .config/dotnet-tools.json vicina, verrà usata la versione dello strumento in tale configurazione anziché la versione più recente disponibile.

dnx Nuovo script di esecuzione dello strumento

Lo dnx script offre un modo semplificato per eseguire gli strumenti. Inoltra tutti gli argomenti all'interfaccia della riga di comando dotnet per l'elaborazione, rendendo l'utilizzo degli strumenti il più semplice possibile.

dnx dotnetsay "Hello, World!"

L'implementazione effettiva del comando dnx si trova nella CLI dotnet stessa, consentendone l'evoluzione del comportamento nel tempo.

Per altre informazioni sulla gestione degli strumenti .NET, vedere Gestire gli strumenti .NET.

any Usare RuntimeIdentifier con strumenti .NET specifici della piattaforma

La funzionalità degli strumenti .NET specifica della piattaforma è ideale per assicurarsi che gli strumenti siano ottimizzati per piattaforme specifiche destinate a una fase anticipata. Tuttavia, ci sono momenti in cui non si conoscono tutte le piattaforme di destinazione, o a volte .NET stesso imparerà a supportare una nuova piattaforma e si vuole che lo strumento sia eseguibile anche lì.

Per fare in modo che lo strumento funzioni in questo modo, aggiungere l'identificatore any di runtime al file di progetto:

<PropertyGroup>
  <RuntimeIdentifiers>
       linux-x64;
       linux-arm64;
       macos-arm64;
       win-x64;
       win-arm64;
       any
  </RuntimeIdentifiers>
</PropertyGroup>

Questo RuntimeIdentifier si trova nella "radice" del controllo della compatibilità della piattaforma e, poiché dichiara il supporto per qualsiasi piattaforma, lo strumento che viene creato in pacchetto sarà il tipo di strumento più compatibile, ovvero una DLL .NET dipendente dal framework, indipendente dalla piattaforma, che richiede l'esecuzione di un runtime .NET compatibile. Quando si esegue un oggetto dotnet pack per creare lo strumento, verrà visualizzato un nuovo pacchetto per any RuntimeIdentifier insieme agli altri pacchetti specifici della piattaforma e al pacchetto manifesto di primo livello.

Introspezione della CLI (interfaccia della riga di comando) con --cli-schema

È disponibile una nuova --cli-schema opzione in tutti i comandi dell'interfaccia della riga di comando. Se usato, restituisce una rappresentazione JSON dell'albero dei comandi dell'interfaccia della riga di comando per il comando o il sottocomando richiamato. Ciò è utile per gli autori di strumenti, l'integrazione della shell e lo scripting avanzato.

dotnet clean --cli-schema

L'output fornisce una descrizione strutturata e leggibile dal computer degli argomenti, delle opzioni e dei sottocomandi del comando:

{
  "name": "clean",
  "version": "10.0.100-dev",
  "description": ".NET Clean Command",
  "arguments": {
    "PROJECT | SOLUTION": {
      "description": "The project or solution file to operate on. If a file is not specified, the command will search the current directory for one.",
      "arity": { "minimum": 0, "maximum": null }
    }
  },
  "options": {
    "--artifacts-path": {
      "description": "The artifacts path. All output from the project, including build, publish, and pack output, will go in subfolders under the specified path.",
      "helpName": "ARTIFACTS_DIR"
    }
  },
  "subcommands": {}
}

Usare attività MSBuild .NET con .NET Framework MSBuild

MSBuild è il sistema di compilazione sottostante per .NET, che guida sia la compilazione di progetti (come nei comandi come dotnet build e dotnet pack) che funge da provider generale di informazioni sui progetti (come nei comandi come dotnet list packagee usati in modo implicito dai comandi come dotnet run per scoprire come un progetto vuole essere eseguito).

Quando si eseguono dotnet comandi dell'interfaccia della riga di comando, la versione di MSBuild usata è quella fornita con .NET SDK. Tuttavia, quando si usa Visual Studio o si richiama direttamente MSBuild, la versione di MSBuild usata è quella installata con Visual Studio. Questa differenza di ambiente ha alcune conseguenze importanti. L'aspetto più importante è che MSBuild in esecuzione in Visual Studio (o tramite msbuild.exe) è un'applicazione .NET Framework, mentre MSBuild in esecuzione nell'interfaccia della dotnet riga di comando è un'applicazione .NET. Ciò significa che tutte le attività di MSBuild scritte per l'esecuzione in .NET non possono essere usate durante la compilazione in Visual Studio o quando si usa msbuild.exe.

A partire da .NET 10 msbuild.exe e Visual Studio 2026 può eseguire attività MSBuild compilate per .NET. Ciò significa che è ora possibile usare le stesse attività di MSBuild durante la compilazione in Visual Studio o usando msbuild.exe durante la compilazione con la dotnet CLI. Per la maggior parte degli utenti .NET, questo non cambierà nulla. Tuttavia, per gli autori di task MSBuild personalizzate, è ora possibile scrivere le task in modo da essere compatibili con .NET e farle funzionare ovunque. L'obiettivo di questa modifica è semplificare la scrittura e la condivisione delle attività di MSBuild e consentire agli autori di attività di sfruttare le funzionalità più recenti in .NET. Questa modifica riduce inoltre le difficoltà relative alle attività di multi-targeting per supportare sia il .NET Framework che .NET e la gestione delle versioni delle dipendenze del .NET Framework disponibili in modo implicito nell'ambiente di esecuzione MSBuild per il .NET Framework.

Configurare le attività .NET

Per gli autori delle attività, è facile scegliere di adottare questo nuovo comportamento. Ti basta modificare la UsingTask dichiarazione per indicare a MSBuild il tuo compito.

<UsingTask TaskName="MyTask"
    AssemblyFile="path\to\MyTask.dll"
    Runtime="NET"
    TaskFactory="TaskHostFactory"
/>

Gli Runtime="NET" attributi e TaskFactory="TaskHostFactory" indicano al motore MSBuild come eseguire l'attività:

• Runtime="NET" indica a MSBuild che l'attività è compilata per .NET (anziché per .NET Framework).
• TaskFactory="TaskHostFactory" indica a MSBuild di usare TaskHostFactory per eseguire l'attività, ovvero una funzionalità esistente di MSBuild che consente l'esecuzione out-of-process delle attività.

Avvertenze e ottimizzazione delle prestazioni

L'esempio precedente è il modo più semplice per iniziare a usare le attività .NET in MSBuild, ma presenta alcune limitazioni. Poiché i TaskHostFactory processi vengono sempre eseguiti fuori dal processo, il nuovo compito .NET viene sempre eseguito in un processo separato da MSBuild. Ciò significa che l'esecuzione dell'attività comporta un sovraccarico minore perché il motore MSBuild e l'attività comunicano tramite la comunicazione tra processi (IPC) anziché la comunicazione in-process. Per la maggior parte delle attività, questo sovraccarico è trascurabile, ma per le attività eseguite molte volte in una compilazione o che eseguono molte registrazioni, questo sovraccarico potrebbe essere più significativo.

Con un po' di lavoro in più, è possibile configurare l'attività per continuare a essere eseguita in-process durante l'esecuzione tramite dotnet.

<UsingTask TaskName="MyTask"
    AssemblyFile="path\to\MyTask.dll"
    Runtime="NET"
    TaskFactory="TaskHostFactory"
    Condition="$(MSBuildRuntimeType) == 'Full'"
/>
<UsingTask TaskName="MyTask"
    AssemblyFile="path\to\MyTask.dll"
    Runtime="NET"
    Condition="$(MSBuildRuntimeType) == 'Core'"
/>

Grazie alla Condition caratteristica di MSBuild, è possibile caricare un'attività in modo diverso a seconda che MSBuild stia girando su .NET Framework (in Visual Studio o msbuild.exe) oppure su .NET (nella CLI dotnet). In questo esempio, il Task viene eseguito out-of-process durante l'esecuzione in Visual Studio o msbuild.exe, ma viene eseguito in modalità in-process durante l'esecuzione nella CLI dotnet. Ciò garantisce prestazioni ottimali durante l'esecuzione nella CLI (interfaccia della riga di comando), consentendo comunque l'uso del task in Visual Studio e dotnet.

Esistono anche piccole limitazioni tecniche da tenere presenti quando si usano attività .NET in MSBuild, la più importante delle quali è che la Host Object funzionalità delle attività di MSBuild non è ancora supportata per le attività .NET che eseguono out-of-process. Ciò significa che se l'attività si basa su un oggetto host, non funzionerà durante l'esecuzione in Visual Studio o msbuild.exe. Il supporto aggiuntivo per gli oggetti host è pianificato nelle versioni future.

Miglioramenti delle app basate su file

.NET 10 offre aggiornamenti significativi all'esperienza delle app basate su file, tra cui il supporto per la pubblicazione e le funzionalità AOT native. Per un'introduzione alle app basate su file, vedere App basate su file e Compilazione ed esecuzione di programmi C#.

App basate su file ottimizzate con supporto per la pubblicazione e AOT nativo

Le app basate su file supportano ora la pubblicazione in file eseguibili nativi tramite il dotnet publish app.cs comando, semplificando la creazione di app semplici che è possibile ridistribuire come eseguibili nativi. Per impostazione predefinita, tutte le app basate su file sono configurate per utilizzare AOT nativo. Se è necessario usare pacchetti o funzionalità incompatibili con AOT nativo, è possibile disabilitare questa operazione usando la #:property PublishAot=false direttiva nel file di .cs.

Le app basate su file includono anche funzionalità avanzate:

• Riferimento al progetto: supporto per fare riferimento ai progetti tramite la #:project direttiva .
• Accesso al percorso di runtime: i percorsi di file e directory dell'app sono disponibili in fase di esecuzione tramite System.AppContext.GetData.
• Supporto avanzato per shebang: esecuzione diretta della shell con gestione migliorata degli shebang, compreso il supporto per i file senza estensione.

Esempio di riferimento al progetto

#:project ../ClassLib/ClassLib.csproj

var greeter = new ClassLib.Greeter();
var greeting = greeter.Greet(args.Length > 0 ? args[0] : "World");
Console.WriteLine(greeting);

Esempio di supporto avanzato per il Shebang

È ora possibile creare file C# eseguibili eseguiti direttamente dalla shell:

#!/usr/bin/env dotnet

Console.WriteLine("Hello shebang!");

Per i file senza estensione:

# 1. Create a single-file C# app with a shebang
cat << 'EOF' > hello.cs
#!/usr/bin/env dotnet
Console.WriteLine("Hello!");
EOF

# 2. Copy it (extensionless) into ~/utils/hello (~/utils is on my PATH)
mkdir -p ~/utils
cp hello.cs ~/utils/hello

# 3. Mark it executable
chmod +x ~/utils/hello

# 4. Run it directly from anywhere
cd ~
hello

Questi miglioramenti rendono le app basate su file più potenti mantenendo al contempo la loro semplicità per scenari di creazione rapida di script e prototipi.

Per altre informazioni su AOT nativo, vedere AOT nativo di .NET.

Eliminazione di riferimenti ai pacchetti forniti dal framework

A partire da .NET 10, la funzionalità Di controllo NuGet può eliminare i riferimenti ai pacchetti forniti dal framework che non vengono usati dal progetto. Questa funzionalità è abilitata di default per tutti i framework di un progetto che mira a > = .NET 10.0 nell'ultima versione dell'SDK. Questa modifica consente di ridurre il numero di pacchetti ripristinati e analizzati durante il processo di compilazione, che può portare a tempi di compilazione più rapidi e a un utilizzo ridotto dello spazio su disco. Può anche comportare una riduzione dei falsi positivi da NuGet Audit e altri meccanismi di analisi delle dipendenze.

Quando questa funzionalità è abilitata, è possibile che venga visualizzata una riduzione del contenuto dei file .deps.json generati dalle applicazioni. Tutti i riferimenti al pacchetto forniti dal runtime .NET vengono rimossi automaticamente dal file di dipendenza generato. Quando un riferimento diretto al pacchetto rientra nell'intervallo di eliminazione, vengono applicati PrivateAssets="all" e IncludeAssets="none".

Sebbene questa funzionalità sia abilitata per impostazione predefinita per i TFM elencati, è possibile disabilitarla impostando la RestoreEnablePackagePruning proprietà su false nel file di progetto o nel file Directory.Build.props .

Ordine dei comandi più coerente

A partire da .NET 10, lo strumento CLI dotnet include nuovi alias per i comandi comuni per renderli più facili da ricordare e digitare. I nuovi comandi sono illustrati nella tabella seguente.

Nuovo formato orientato al sostantivo	Alias per
dotnet package add	dotnet add package
dotnet package list	dotnet list package
dotnet package remove	dotnet remove package
dotnet reference add	dotnet add reference
dotnet reference list	dotnet list reference
dotnet reference remove	dotnet remove reference

Le nuove forme prima il sostantivo sono allineate agli standard generali dell'interfaccia a riga di comando, rendendo l'interfaccia a riga di comando dotnet più coerente con altri strumenti. Sebbene le forme verbo-primo continuino a funzionare, è preferibile usare le forme nome-primo per migliorare la leggibilità e la coerenza negli script e nella documentazione.

Per impostazione predefinita, i comandi dell'interfaccia della riga di comando operano in modalità interattiva nei terminali interattivi.

Il --interactive flag è ora abilitato per impostazione predefinita per i comandi dell'interfaccia della riga di comando nei terminali interattivi. Questa modifica consente ai comandi di recuperare in modo dinamico le credenziali o di eseguire altri comportamenti interattivi senza che il flag venga impostato in modo esplicito. Per gli scenari non interattivi, è possibile disabilitare l'interattività specificando --interactive false.

Script di completamento tramite tabulazione della shell nativa

L'interfaccia CLI ora supporta la generazione di script di completamento nativi per le shell più diffuse, utilizzando il comando dotnet. Le shell supportate includono bash, fish, nushell, powershell, e zsh. Questi script migliorano l'usabilità offrendo funzionalità di completamento schede più veloci e integrate. Ad esempio, in PowerShell è possibile abilitare i completamenti aggiungendo quanto segue a $PROFILE:

dotnet completions script pwsh | Out-String | Invoke-Expression

Le app console possono creare immagini del contenitore in modo nativo

Le app console possono ora creare immagini contenitore tramite dotnet publish /t:PublishContainer senza richiedere la <EnableSdkContainerSupport> proprietà nel file di progetto. In questo modo le app console vengono allineate al comportamento delle app Core e Worker SDK di ASP.NET.

Controllare in modo esplicito il formato di immagine dei contenitori

Una nuova <ContainerImageFormat> proprietà consente di impostare in modo esplicito il formato delle immagini del contenitore su Docker o OCI. Questa proprietà esegue l'override del comportamento predefinito, che dipende dal formato dell'immagine di base e dal fatto che il contenitore sia multiarchitettura.

Supporto per Microsoft Testing Platform in dotnet test

A partire da .NET 10, dotnet test supporta in modo nativo Microsoft.Testing.Platform. Per abilitare questa funzionalità, aggiungere la configurazione seguente al file global.json :

{
    "test": {
        "runner": "Microsoft.Testing.Platform"
    }
}

Per altri dettagli, vedere Test con dotnet test.