Nouveautés du Kit de développement logiciel (SDK) et des outils pour .NET 10

Cet article décrit les nouvelles fonctionnalités et améliorations du Kit de développement logiciel (SDK) .NET pour .NET 10.

Améliorations apportées aux outils .NET

Outils .NET spécifiques à la plateforme

Les outils .NET peuvent désormais être publiés avec prise en charge de plusieurs RUNTIMEIdentifiers (RID) dans un seul package. Les auteurs d’outils peuvent regrouper des fichiers binaires pour toutes les plateformes prises en charge, et l’interface CLI .NET sélectionne la valeur appropriée lors de l’installation ou de l’exécution. Cela facilite considérablement la création et la distribution d’outils multiplateformes.

Ces outils améliorés prennent en charge différentes variantes d’empaquetage :

• Dépendant de l’infrastructure, indépendant de la plateforme (mode classique, s’exécute n’importe où avec .NET 10 installé)
• Dépendant de l’infrastructure, propre à la plateforme (plus petit, optimisé pour chaque plateforme)
• Autonome, spécifique à la plateforme (inclut le runtime, aucune installation .NET requise)
• Rogné, spécifique à la plateforme (plus petit, supprime le code inutilisé)
• AOT-compiled, spécifique à la plateforme (performances maximales et déploiement minimal)

Ces nouveaux outils fonctionnent de manière similaire aux applications publiées classiques, donc toutes les options de publication que vous pouvez utiliser avec des applications (par exemple, autonomes, réduites ou AOT) peuvent également s’appliquer aux outils.

Exécution ponctuelle d’un outil

Vous pouvez maintenant utiliser la dotnet tool exec commande pour exécuter un outil .NET sans l’installer globalement ou localement. Cela est particulièrement utile pour une utilisation dans un contexte CI/CD ou temporaire.

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 /   | (_) | | |    | | | (_| | |_|
 |_| |_|  \___| |_| |_|  \___/  ( )      \_/\_/     \___/  |_|    |_|  \__,_| (_)
                                |/

Cette opération télécharge et exécute le package d’outils spécifié dans une seule commande. Par défaut, les utilisateurs sont invités à confirmer le téléchargement si l’outil n’existe pas déjà localement. La dernière version du package d’outils choisi est utilisée, sauf si une version explicite est spécifiée (par exemple). dotnetsay@0.1.0

L'exécution d'un outil unique fonctionne sans heurt avec les manifestes d'outils locaux. Si vous exécutez un outil depuis un emplacement avec .config/dotnet-tools.json à proximité, la version de l'outil dans cette configuration sera utilisée au lieu de la dernière version disponible.

dnx Nouveau script d’exécution d’outil

Le dnx script offre un moyen simplifié d’exécuter des outils. Il transfère tous les arguments à l’interface dotnet CLI pour le traitement, ce qui rend l’utilisation de l’outil aussi simple que possible :

dnx dotnetsay "Hello, World!"

L’implémentation réelle de la dnx commande se trouve dans l’interface dotnet CLI elle-même, ce qui permet à son comportement d’évoluer au fil du temps.

Pour plus d’informations sur la gestion des outils .NET, consultez Gérer les outils .NET.

Utiliser RuntimeIdentifier avec des outils .NET spécifiques à la any plateforme

La fonctionnalité d’outils .NET spécifiques à la plateforme est idéale pour vous assurer que les outils sont optimisés pour des plateformes spécifiques que vous ciblez à l’avance. Toutefois, il existe des moments où vous ne connaissez pas toutes les plateformes que vous souhaitez cibler, ou parfois .NET lui-même apprendra à prendre en charge une nouvelle plateforme, et vous souhaitez que votre outil soit également exécutable.

Pour que votre outil fonctionne de cette façon, ajoutez l’identificateur d’exécution any à votre fichier projet :

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

Ce RuntimeIdentifier est à la « racine » de la vérification de compatibilité de la plateforme et, étant donné qu’il déclare la prise en charge de n’importe quelle plateforme, l’outil qui est empaqueté sera le type d’outil le plus compatible - une DLL .NET dépendante du framework, indépendant de la plateforme, qui nécessite un runtime .NET compatible pour s’exécuter. Lorsque vous effectuez une dotnet pack opération pour créer votre outil, vous verrez un nouveau package pour any RuntimeIdentifier s’afficher en même temps que les autres packages spécifiques à la plateforme et le package manifeste de niveau supérieur.

Introspection CLI avec --cli-schema

Une nouvelle --cli-schema option est disponible sur toutes les commandes CLI. Lorsqu’elle est utilisée, elle génère une représentation JSON de l’arborescence de commandes CLI pour la commande ou la sous-commande appelée. Cela est utile pour les auteurs d’outils, l’intégration d’interpréteur de commandes et les scripts avancés.

dotnet clean --cli-schema

La sortie fournit une description structurée et lisible par l’ordinateur des arguments, des options et des sous-commandes de la commande :

{
  "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": {}
}

Utiliser des tâches .NET MSBuild avec .NET Framework MSBuild

MSBuild est le système de génération sous-jacent pour .NET, qui pilote à la fois la génération de projets (comme indiqué dans les commandes comme dotnet build et dotnet pack) et agit en tant que fournisseur général d’informations sur les projets (comme dans les commandes telles dotnet list packageque , et implicitement utilisés par les commandes comme dotnet run pour découvrir comment un projet souhaite être exécuté).

Lors de l’exécution dotnet de commandes CLI, la version de MSBuild utilisée est celle fournie avec le Kit de développement logiciel (SDK) .NET. Toutefois, lors de l’utilisation de Visual Studio ou de l’appel de MSBuild directement, la version de MSBuild utilisée est celle installée avec Visual Studio. Cette différence d’environnement a quelques conséquences importantes. Le plus important est que MSBuild s’exécutant dans Visual Studio (ou via msbuild.exe) est une application .NET Framework, tandis que MSBuild s’exécutant dans l’interface dotnet CLI est une application .NET. Cela signifie que toutes les tâches MSBuild écrites pour s’exécuter sur .NET ne peuvent pas être utilisées lors de la génération dans Visual Studio ou lors de l’utilisation msbuild.exe.

À compter de .NET 10, msbuild.exe et Visual Studio 2026 peuvent exécuter des tâches MSBuild conçues pour .NET. Cela signifie que vous pouvez désormais utiliser les mêmes tâches MSBuild lors de la génération dans Visual Studio ou lors de l'utilisation de msbuild.exe, comme vous le faites lors de la génération avec l'interface dotnet CLI. Pour la plupart des utilisateurs .NET, cela ne changera rien. Toutefois, pour les auteurs de tâches MSBuild personnalisées, cela signifie que vous pouvez désormais écrire vos tâches pour cibler .NET et les faire fonctionner partout. L’objectif de cette modification est de faciliter l’écriture et le partage des tâches MSBuild et de permettre aux auteurs de tâches de tirer parti des dernières fonctionnalités de .NET. En outre, cette modification réduit les difficultés liées aux tâches multi-ciblage pour prendre en charge .NET Framework et .NET, et traiter les versions des dépendances .NET Framework qui sont implicitement disponibles dans l’espace d’exécution MSBuild .NET Framework.

Configurer des tâches .NET

Pour les auteurs de tâches, il est facile d’opter pour ce nouveau comportement. Modifiez simplement votre UsingTask déclaration pour indiquer à MSBuild à propos de votre tâche.

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

Les attributs Runtime="NET" et TaskFactory="TaskHostFactory" indiquent au moteur MSBuild comment exécuter la tâche :

• Runtime="NET" indique à MSBuild que la tâche est générée pour .NET (par opposition à .NET Framework).
• TaskFactory="TaskHostFactory" indique à MSBuild d'utiliser le TaskHostFactory pour exécuter la tâche, une fonctionnalité déjà présente dans MSBuild qui permet d'exécuter des tâches hors processus.

Mises en garde et réglage des performances

L’exemple précédent est le moyen le plus simple de commencer à utiliser des tâches .NET dans MSBuild, mais il présente certaines limitations. Étant donné que les TaskHostFactory tâches sont toujours hors processus, la nouvelle tâche .NET s’exécute toujours dans un processus distinct de MSBuild. Cela signifie qu'il existe une surcharge mineure pour exécuter la tâche, car le moteur MSBuild et la tâche communiquent via la communication inter-processus (IPC) au lieu de la communication intra-processus. Pour la plupart des tâches, cette surcharge est négligeable, mais pour les tâches qui sont exécutées plusieurs fois dans une build, ou qui effectuent beaucoup de journalisation, cette surcharge peut être plus importante.

Avec un peu plus de travail, vous pouvez configurer la tâche pour qu’elle s’exécute toujours en cours d’exécution lors de l’exécution via 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'"
/>

Grâce à la Condition fonctionnalité de MSBuild, vous pouvez charger une tâche différemment selon que MSBuild est en cours d’exécution dans .NET Framework (Visual Studio ou msbuild.exe) ou .NET (l’interface dotnet CLI). Dans cet exemple, la tâche s’exécute hors processus lors de l’exécution dans Visual Studio ou msbuild.exe, mais s’exécute en cours d’exécution dans l’interface dotnet CLI. Cela offre les meilleures performances lors de l’exécution dans l’interface dotnet CLI, tout en autorisant l’utilisation de la tâche dans Visual Studio et msbuild.exe.

Il existe également de petites limitations techniques à prendre en compte lors de l’utilisation de tâches .NET dans MSBuild, dont la plus notable est que la Host Object fonctionnalité des tâches MSBuild n’est pas encore prise en charge pour les tâches .NET en cours d’exécution hors processus. Cela signifie que si votre tâche s’appuie sur un objet hôte, elle ne fonctionnera pas lors de l’exécution dans Visual Studio ou msbuild.exe. Une prise en charge supplémentaire des objets hôtes est prévue dans les versions ultérieures.

Améliorations apportées aux applications basées sur des fichiers

.NET 10 apporte des mises à jour significatives à l’expérience des applications basées sur fichiers, notamment la prise en charge des publications et les capacités natives AOT. Pour une présentation des applications basées sur des fichiers, consultez Applications basées sur des fichiers et Génération et exécution de programmes C#.

Applications basées sur des fichiers améliorées avec prise en charge de la publication et AOT natif

Les applications basées sur des fichiers prennent désormais en charge la publication sur des exécutables natifs via la dotnet publish app.cs commande, ce qui facilite la création d’applications simples que vous pouvez redistribuer en tant qu’exécutables natifs. Toutes les applications basées sur des fichiers ciblent désormais l’AOT natif par défaut. Si vous devez utiliser des packages ou des fonctionnalités incompatibles avec AOT natif, vous pouvez désactiver cette option à l’aide de la #:property PublishAot=false directive dans votre fichier .cs.

Les applications basées sur des fichiers incluent également des fonctionnalités améliorées :

• Référencement de projet : prise en charge du référencement de projets via la #:project directive.
• Accès au chemin d’exécution : les chemins d’accès aux fichiers et répertoires d’application sont disponibles au moment de l’exécution via System.AppContext.GetData.
• Prise en charge améliorée du shebang : exécution directe via interpréteur de commandes avec une gestion améliorée du shebang, y compris la prise en charge des fichiers sans extension.

Exemple de référencement de projet

#:project ../ClassLib/ClassLib.csproj

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

Exemple de prise en charge améliorée du shebang

Vous pouvez maintenant créer des fichiers C# exécutables qui s’exécutent directement à partir de l’interpréteur de commandes :

#!/usr/bin/env dotnet

Console.WriteLine("Hello shebang!");

Pour les fichiers sans extension :

# 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

Ces améliorations rendent les applications basées sur des fichiers plus puissantes tout en conservant leur simplicité pour les scénarios de script rapide et de prototypage.

Pour plus d’informations sur AOT natif, consultez .NET native AOT.

Nettoyage des références de packages fournies par le framework

À compter de .NET 10, la fonctionnalité NuGet Audit peut élaguer les références de packages fournies par le framework qui ne sont pas utilisées par le projet. Cette fonctionnalité est activée par défaut pour toutes les infrastructures d’un projet qui cible >= .NET 10.0 dans le dernier SDK. Cette modification permet de réduire le nombre de packages restaurés et analysés pendant le processus de génération, ce qui peut entraîner des temps de génération plus rapides et une utilisation réduite de l’espace disque. Il peut également entraîner une réduction des faux positifs de NuGet Audit et d’autres mécanismes d’analyse des dépendances.

Lorsque cette fonctionnalité est activée, vous pouvez voir une réduction du contenu des fichiers .deps.json générés par vos applications. Toutes les références de package fournies par le runtime .NET sont automatiquement supprimées du fichier de dépendance généré. Lorsqu’une référence de package directe se trouve dans la plage d’élagage, PrivateAssets="all" et IncludeAssets="none" sont appliqués.

Bien que cette fonctionnalité soit activée par défaut pour les TFMs listées, vous pouvez la désactiver en définissant la propriété RestoreEnablePackagePruning à false dans votre fichier de projet ou dans le fichier Directory.Build.props.

Ordre de commande plus cohérent

À compter de .NET 10, l’outil dotnet CLI inclut de nouveaux alias pour les commandes courantes afin de les rendre plus faciles à mémoriser et à taper. Les nouvelles commandes sont affichées dans le tableau suivant.

Les nouvelles formes avec le nom en premier s’alignent sur les normes CLI générales, ce qui rend le CLI dotnet plus cohérent avec d’autres outils. Bien que les formes verbales en premier continuent de fonctionner, il est préférable d’utiliser les formes nominales en premier pour une meilleure lisibilité et cohérence dans les scripts et la documentation.

Les commandes CLI sont par défaut en mode interactif dans les terminaux interactifs.

L’indicateur --interactive est désormais activé par défaut pour les commandes CLI dans les terminaux interactifs. Cette modification permet aux commandes de récupérer dynamiquement des informations d’identification ou d’effectuer d’autres comportements interactifs sans que l’indicateur soit défini explicitement. Pour les scénarios non interactifs, vous pouvez désactiver l’interactivité en spécifiant --interactive false.

Scripts natifs de complétion par tabulation pour l’interpréteur de commandes

La CLI dotnet prend désormais en charge la génération de scripts natifs de complétion par tabulation pour les interpréteurs de commandes les plus courants à l’aide de la commande dotnet completions script [SHELL]. Les interpréteurs de commandes pris en charge incluent bash, fish, nushell, powershell, et zsh. Ces scripts améliorent la facilité d’utilisation en fournissant des fonctionnalités d’achèvement de tabulation plus rapides et plus intégrées. Par exemple, dans PowerShell, vous pouvez activer les achèvements en ajoutant ce qui suit à votre $PROFILE:

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

Les applications console peuvent créer des images conteneur en mode natif

Les applications console peuvent désormais créer des images conteneur via dotnet publish /t:PublishContainer sans nécessiter la propriété <EnableSdkContainerSupport> dans le fichier projet. Cela aligne les applications console avec le comportement des applications ASP.NET Kit de développement logiciel (SDK) Core et Worker.

Contrôler explicitement le format d’image des conteneurs

Une nouvelle <ContainerImageFormat> propriété vous permet de définir explicitement le format d’images conteneur sur Docker ou OCI. Cette propriété remplace le comportement par défaut, qui dépend du format d’image de base et si le conteneur est multi-architecture.

Prise en charge de Microsoft Testing Platform dans dotnet test

À compter de .NET 10, dotnet test prend en charge Microsoft.Testing.Platform en mode natif. Pour activer cette fonctionnalité, ajoutez la configuration suivante à votre fichier global.json :

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

Pour plus d’informations, consultez Test avec dotnet test.