Partage via

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

Cet article décrit les nouvelles fonctionnalités du Kit de développement logiciel (SDK) .NET et des outils pour .NET 9.

Test des unités

Cette section décrit les mises à jour des tests unitaires dans .NET 9 : exécution de tests en parallèle et sortie de test Terminal Logger.

Exécuter des tests en parallèle

Dans .NET 9, dotnet test est plus entièrement intégré à MSBuild. Étant donné que MSBuild prend en charge la génération en parallèle, vous pouvez exécuter des tests pour le même projet sur différents frameworks cibles en parallèle. Par défaut, MSBuild limite le nombre de processus parallèles au nombre de processeurs sur l’ordinateur. Vous pouvez également définir votre propre limite à l’aide du commutateur -maxcpucount . Si vous souhaitez désactiver le parallélisme, définissez la propriété TestTfmsInParallelfalse MSBuild sur la valeur souhaitée.

Affichage du test Terminal Logger

La création de rapports de résultats de test pour dotnet test est désormais prise en charge directement dans MSBuild Terminal Logger. Vous obtenez des rapports de test plus complets tant que les tests sont en cours d’exécution (affiche le nom du test en cours d’exécution) et une fois les tests terminés (toutes les erreurs de test sont rendues de manière optimale).

Pour plus d’informations sur Terminal Logger, consultez les options de build dotnet.

Fonction de roll-forward de l’outil .NET

Les outils .NET sont des applications dépendantes du framework que vous pouvez installer globalement ou localement, puis s’exécuter à l’aide du Kit de développement logiciel (SDK) .NET et des runtimes .NET installés. Ces outils, comme toutes les applications .NET, ciblent une version majeure spécifique de .NET. Par défaut, les applications ne s’exécutent pas sur les versions plus récentes de .NET. Les auteurs d’outils ont pu choisir d’exécuter leurs outils sur des versions plus récentes du runtime .NET en définissant la RollForward propriété MSBuild. Toutefois, tous les outils ne le font pas.

Une nouvelle option pour dotnet tool install permettre aux utilisateurs de décider de la façon dont les outils .NET doivent être exécutés. Lorsque vous installez un outil via dotnet tool install, ou lorsque vous exécutez l’outil via dotnet tool run <toolname>, vous pouvez spécifier un nouvel indicateur appelé --allow-roll-forward. Cette option configure l’outil en mode Majorroll-forward. Ce mode permet à l’outil d’exécuter sur une version majeure plus récente de .NET si la version .NET correspondante n’est pas disponible. Cette fonctionnalité permet aux utilisateurs précoces d’utiliser les outils .NET sans que les auteurs d’outils n’ont à modifier du code.

Journaliseur de terminal

Terminal Logger est désormais activé par défaut et a également amélioré la facilité d’utilisation.

Activée par défaut

À compter de .NET 9, l’expérience par défaut pour toutes les commandes CLI .NET qui utilisent MSBuild est Terminal Logger, l’expérience de journalisation améliorée qui a été publiée dans .NET 8. Cette nouvelle sortie utilise les fonctionnalités des terminaux modernes pour fournir des fonctionnalités telles que :

  • Liens cliquables
  • Minuteurs de durée pour les tâches MSBuild
  • Codage de couleur des messages d’avertissement et d’erreur

La sortie est plus condensée et utilisable que l’enregistreur d’événements de console MSBuild existant.

Le nouvel enregistreur d’événements tente de détecter automatiquement s’il peut être utilisé, mais vous pouvez également contrôler manuellement si Terminal Logger est utilisé. Spécifiez l’option --tl:off de ligne de commande pour désactiver Terminal Logger pour une commande spécifique. Ou, pour désactiver Terminal Logger plus largement, définissez la variable MSBUILDTERMINALLOGGERd’environnement off sur .

L’ensemble de commandes qui utilise Terminal Logger par défaut est :

  • build
  • clean
  • msbuild
  • pack
  • publish
  • restore
  • test

Usability

Terminal Logger récapitule désormais le nombre total d’échecs et d’avertissements à la fin d’une build. Il affiche également des erreurs qui contiennent des lignes de nouvelle ligne. (Pour plus d’informations sur Terminal Logger, consultez les options « dotnet build », en particulier l’option --tl .)

Tenez compte du fichier projet suivant qui émet un avertissement lorsque le projet est généré :

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>

  <Target Name="Error" BeforeTargets="Build">
    <Warning Code="ECLIPSE001" Text="Black Hole Sun, won't you come
  And wash away the rain
    Black Hole Sun, won't you come
      won't you come" />
  </Target>
</Project>

Lorsque vous exécutez dotnet build -tl le Kit de développement logiciel (SDK) .NET 8, la sortie se présente comme indiqué dans ce paragraphe. Chaque ligne de l’avertissement à plusieurs lignes est une ligne distincte avec un préfixe de message d’erreur complet dans la sortie, ce qui est difficile à lire. En outre, le résumé final de la compilation indique qu’il y avait des avertissements, mais pas combien il y en avait. Les informations manquantes peuvent rendre difficiles à déterminer si une build particulière est meilleure ou pire que les builds précédentes.

$ dotnet build -tl
MSBuild version 17.8.5+b5265ef37 for .NET
Restore complete (0.5s)
  multiline-error-example succeeded with warnings (0.2s) → bin\Debug\net8.0\multiline-error-example.dll
    E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001: Black Hole Sun, won't you come
E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:   And wash away the rain
E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:     Black Hole Sun, won't you come
E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:       won't you come
Build succeeded with warnings in 0.9s

Lorsque vous générez le même projet à l’aide du Kit de développement logiciel (SDK) .NET 9, la sortie est la suivante :

> dotnet build -tl
Restore complete (0.4s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  multiline-error-example succeeded with 3 warning(s) (0.2s) → bin\Debug\net8.0\multiline-error-example.dll
    E:\Code\multiline-error-example.csproj(11,5): warning ECLIPSE001:
      Black Hole Sun, won't you come
        And wash away the rain
          Black Hole Sun, won't you come
            won't you come
Build succeeded with 3 warning(s) in 0.8s

Les lignes de message de l’avertissement n’ont plus les informations de projet et d’emplacement répétées qui encombrent l’affichage. En outre, le résumé de la compilation indique le nombre d’avertissements (et d’erreurs, le cas échéant) qui ont été générés pendant la compilation.

Si vous avez des commentaires sur Terminal Logger, vous pouvez le fournir dans le référentiel MSBuild.

Résolution de dépendance NuGet plus rapide pour les dépôts volumineux

Le programme de résolution des dépendances NuGet a été révisé pour améliorer les performances et l’extensibilité de tous les <PackageReference> projets. Activé par défaut, le nouvel algorithme accélère les opérations de restauration sans compromettre les fonctionnalités, respectant strictement les règles de résolution de dépendances principales.

Si vous rencontrez des problèmes, tels que des échecs de restauration ou des versions inattendues du package, vous pouvez revenir au programme de résolution hérité.

Analyseurs de script MSBuild (« BuildChecks »)

.NET 9 introduit une fonctionnalité qui permet de se protéger contre les défauts et les régressions dans vos scripts de build. Pour exécuter les vérifications de build, ajoutez l’indicateur /check à n’importe quelle commande qui appelle MSBuild. Par exemple, dotnet build myapp.sln /check génère la myapp solution et exécute toutes les vérifications de build configurées.

Le KIT SDK .NET 9 inclut un petit nombre de vérifications initiales, par exemple BC0101 et BC0102. Pour obtenir une liste complète, consultez les codes BuildCheck.

Lorsqu’un problème est détecté, un diagnostic est généré dans la sortie de build du projet qui contient le problème.

Pour plus d’informations, consultez la documentation de conception.

Incompatibilité de l’analyseur

De nombreux utilisateurs installent le Kit de développement logiciel (SDK) .NET et Visual Studio à différentes cadences. Bien que cette flexibilité soit souhaitable, elle peut entraîner des problèmes pour les outils qui doivent interagir entre les deux environnements. Un exemple de ce type d’outils est Roslyn Analyzers. Les auteurs d’analyseurs doivent coder pour des versions spécifiques de Roslyn, mais les versions disponibles et utilisées par une build donnée sont parfois peu claires.

Ce type d'incompatibilité de version entre le Kit de développement logiciel (SDK) .NET et MSBuild est appelé une incompatibilité de SDK. Lorsque vous êtes dans cet état, vous pouvez voir des erreurs comme ceci :

CSC : avertissement CS9057 : Assembly de l’analyseur '..\dotnet\sdk\8.0.200\Sdks\Microsoft.NET.Sdk.Razor\source-generators\Microsoft.CodeAnalysis.Razor.Compiler.SourceGenerators.dll' référence la version '4.9.0.0' du compilateur, qui est plus récente que la version en cours d’exécution '4.8.0.0'.

.NET 9 peut détecter et ajuster automatiquement ce scénario de problème. La logique MSBuild du Kit de développement logiciel (SDK) intègre la version de MSBuild avec laquelle il a été livré, et ces informations peuvent être utilisées pour détecter quand le SDK s’exécute dans un environnement avec une version différente. Dans ce cas, le SDK insère un téléchargement implicite d’un package de support appelé Microsoft.Net.Sdk.Compilers.Toolset qui garantit une expérience d’analyseur cohérente.

Ensembles de charges de travail

Les ensembles de charges de travail sont une fonctionnalité du Kit de développement logiciel (SDK) destinée à permettre aux utilisateurs de contrôler davantage les charges de travail qu’ils installent et la cadence de modification de ces charges de travail. Dans les versions précédentes, les charges de travail ont été régulièrement mises à jour à mesure que de nouvelles versions de charges de travail individuelles ont été publiées sur tous les flux NuGet configurés. À présent, toutes vos charges de travail restent à une version unique spécifique jusqu’à ce que vous effectuiez un mouvement de mise à jour explicite.

Vous pouvez voir le mode dans lequel se trouve votre installation du Kit de développement logiciel (SDK) en exécutant dotnet workload --info:

> dotnet workload --info
Workload version: 9.0.100-manifests.400dd185
Configured to use loose manifests when installing new manifests.
 [aspire]
   Installation Source: VS 17.10.35027.167, VS 17.11.35111.106
   Manifest Version:    8.0.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.0.2\WorkloadManifest.json
   Install Type:              Msi

Dans cet exemple, l’installation du Kit de développement logiciel (SDK) est en mode « manifeste », où les mises à jour sont installées au fur et à mesure qu’elles sont disponibles. Pour choisir le nouveau mode, ajoutez une option --version à une commande dotnet workload install ou dotnet workload update. Vous pouvez également contrôler explicitement votre mode d’opération à l’aide de la nouvelle dotnet workload config commande :

> dotnet workload config --update-mode workload-set
Successfully updated workload install mode to use workload-set.

Si vous avez besoin de revenir en arrière pour une raison quelconque, vous pouvez exécuter la même commande avec manifests au lieu de workload-set. Vous pouvez également utiliser dotnet workload config --update-mode pour vérifier le mode actuel d’opération.

Pour plus d’informations, consultez les ensembles de charges de travail du Kit de développement logiciel (SDK) .NET.

Historique des charges de travail

Les charges de travail du Kit de développement logiciel (SDK) .NET font partie intégrante de .NET MAUI et Blazor WebAssembly. Dans leur configuration par défaut, vous pouvez mettre à jour les charges de travail indépendamment en tant qu’auteurs d’outils .NET publient de nouvelles versions. En outre, les installations du Kit de développement logiciel (SDK) .NET effectuées via Visual Studio installent un ensemble parallèle de versions. Sans prendre soin, l’état d’installation de la charge de travail d’une installation donnée du Kit de développement logiciel (SDK) .NET peut dériver au fil du temps, mais il n’y a pas eu de moyen de visualiser cette dérive.

Pour résoudre ce problème, .NET 9 ajoute une nouvelle dotnet workload history commande au Kit de développement logiciel (SDK) .NET. dotnet workload history imprime une table de l’historique des installations de charge de travail et des modifications pour l’installation actuelle du Kit de développement logiciel (SDK) .NET. Le tableau indique la date de l’installation ou de la modification, la commande qui a été exécutée, les charges de travail qui ont été installées ou modifiées et les versions appropriées pour la commande. Ce résultat peut vous aider à comprendre l'évolution des installations des charges de travail au fil du temps et vous aider à prendre des décisions éclairées sur les versions des charges de travail à sélectionner pour votre installation. Vous pouvez le considérer comme git reflog pour les charges de travail.

> dotnet workload history

Id  Date                         Command       Workloads                                        Global.json Version  Workload Version
-----------------------------------------------------------------------------------------------------------------------------------------------
1   1/1/0001 12:00:00 AM +00:00  InitialState  android, ios, maccatalyst, maui-windows                               9.0.100-manifests.6d3c8f5d
2   9/4/2024 8:15:33 PM -05:00   install       android, aspire, ios, maccatalyst, maui-windows                       9.0.100-rc.1.24453.3

Dans cet exemple, le Kit de développement logiciel (SDK) a été initialement installé avec les charges de travail android, ios, maccatalyst, et maui-windows. Ensuite, la dotnet workload install aspire --version 9.0.100-rc.1.24453.3 commande a été utilisée pour installer la aspire charge de travail et basculer en mode ensembles de charges de travail. Pour revenir à l’état précédent, vous pouvez utiliser l’ID de la première colonne de la table d’historique, par exemple dotnet workload update --from-history 1.

Containers

Support de publication pour les registres non sécurisés

La prise en charge intégrée de publication de conteneurs du SDK permet de publier des images sur des registres de conteneurs. Jusqu’à ce que .NET 9, ces registres devaient être sécurisés. Pour que le Kit de développement logiciel (SDK) .NET fonctionne, ils ont besoin de la prise en charge HTTPS et des certificats valides. Les moteurs de conteneur peuvent généralement être configurés pour fonctionner avec des registres non sécurisés, c’est-à-dire des registres qui n’ont pas configuré TLS ou qui ont configuré TLS avec un certificat non valide. Il s’agit d’un cas d’usage valide, mais nos outils ne prenaient pas en charge ce mode de communication.

À compter de .NET 9, le Kit de développement logiciel (SDK) peut communiquer avec des registres non sécurisés.

Exigences (en fonction de votre environnement) :

  • Configurez l’interface CLI Docker pour marquer un registre comme non sécurisé.
  • Configurez Podman pour marquer un registre comme non sécurisé.
  • Utilisez la DOTNET_CONTAINER_INSECURE_REGISTRIES variable d’environnement pour passer une liste délimitée par des points-virgules de domaines de Registre pour les traiter comme non sécurisés.

Nommage des variables d’environnement

Les variables d’environnement utilisées par l’outil de publication de conteneur pour contrôler certains aspects plus précis de la communication et de la sécurité du Registre commencent maintenant par le préfixe DOTNET au lieu de SDK. Le SDK préfixe continuera d’être pris en charge dans un avenir proche.

Analyse du code

.NET 9 inclut plusieurs nouveaux analyseurs de code et correctifs pour vous aider à vérifier que vous utilisez des API de bibliothèque .NET correctement et efficacement. Le tableau suivant récapitule les nouveaux analyseurs.

ID de règle Catégorie Descriptif
CA1514 : Éviter l’argument de longueur redondante Maintenabilité Un argument de longueur calculé explicitement peut être sujet à des erreurs et n’est pas nécessaire lorsque vous coupez jusqu'à la fin d’une chaîne ou d’un tampon.
CA1515 : Envisagez de rendre internes les types publics Maintenabilité Les types à l’intérieur d’un assembly exécutable doivent être déclarés en tant que internal.
CA1871 : Ne passez pas de struct nullable à 'ArgumentNullException.ThrowIfNull' Performance Pour améliorer les performances, il est préférable de vérifier la HasValue propriété et de lever manuellement une exception que de passer un struct nullable à ArgumentNullException.ThrowIfNull.
CA1872 : Préférer « Convert.ToHexString » et « Convert.ToHexStringLower » sur les chaînes d’appels basées sur « BitConverter.ToString » Performance Utilisez Convert.ToHexString ou Convert.ToHexStringLower lors de l’encodage d’octets dans une représentation sous forme de chaîne hexadécimale.
CA2022 : Éviter une lecture inexacte avec Stream.Read Reliability Un appel à Stream.Read peut retourner un nombre d’octets inférieur à celui demandé, ce qui entraîne un code non fiable si la valeur de retour n’est pas vérifiée.
CA2262 : Définir correctement « MaxResponseHeadersLength » Usage La HttpClientHandler.MaxResponseHeadersLength propriété est mesurée en kilo-octets, et non en octets.
CA2263 : Préférer la surcharge générique lorsque le type est connu Usage Les surcharges génériques sont préférables aux surcharges qui acceptent un argument de type System.Type lorsque le type est connu au moment de la compilation.
CA2264 : Ne passez pas de valeur non nullable à « ArgumentNullException.ThrowIfNull ». Usage Certaines constructions telles que les structs non nullables (à l'exception des structs mentionnés par Nullable<T>), les expressions « nameof() » et « new » sont connues pour ne jamais être null, de sorte que ArgumentNullException.ThrowIfNull ne sera jamais lancé.
CA2265 : Ne pas comparer Span<T> à null ou par défaut Usage Comparer une plage à null ou à default peut ne pas faire ce que vous aviez prévu. default et le null littéral sont implicitement convertis en Span<T>.Empty. Supprimez la comparaison redondante ou rendez le code plus explicite à l’aide IsEmptyde .
  • Last updated on