Les choses avancent pour la version 11 de la plateforme de développement logiciel .NET de Microsoft avec la deuxième déclinaison de la version test publiée le 10 mars dernier (la version finale est attendue en novembre prochain). Parmi les évolutions, on note la fonction Asynchrone native runtim et un SDK plus léger pour Linux et macOS. Sur le premier point, le compilateur ne génère plus de classes de state machine, c’est le runtime lui-même qui gère désormais la suspension et la reprise asynchrones. Cette avancée permet d’obtenir des traces de pile (ou d’exécution) plus claires, un meilleur débogage et une charge système réduite.

Cependant, l’Asynchrone native runtime reste une fonctionnalité en test. Le compilateur doit émettre des méthodes avec MethodImplOptions.Async pour que le runtime les traite comme asynchrones au niveau de l’exécution. Toujours à propos du runtime, le JIT élimine à présent la vérification des limites pour le cas de figure courant où un index plus une constante est comparé à une longueur. Les contextes arithmétiques vérifiés qui s'avèrent redondants sont également optimisés.

Optimisation du SDK

Pour le SDK, la taille des programmes d’installation sous Linux et macOS a été réduite grâce à la déduplication des assemblages à l'aide de liens symboliques. Les fichiers .dll et .exe en double sont identifiés par leur hachage de contenu et remplacés par des liens symboliques pointant vers une seule copie. Cela concerne aussi bien les archives tar que les programmes d'installation .pkg, .deb et .rpm.

Des améliorations ont été apportées à l'analyseur de code dans le SDK afin d'éviter une journalisation potentiellement coûteuse. Les accès aux propriétés, ainsi que les appels à GetType(), GetHashCode() et GetTimestamp(), ne sont plus signalés. Par défaut, les diagnostics s'appliquent désormais uniquement au niveau Information et aux niveaux inférieurs, car les chemins de code d'avertissement/erreur/critique sont rarement des chemins fréquents. De plus, les messages de diagnostic indiquent dorénavant pourquoi un argument a été signalé, ce qui aide les développeurs à hiérarchiser les avertissements à traiter. A noter qu’au sein des bibliothèques .NET 11, les surcharges de de TarFile.CreateFromDirectory acceptent un paramètre TarEntryFormat, offrant un contrôle direct sur le format d'archive (dotnet/runtime#123407). Auparavant, CreateFromDirectory produisait des archives Pax. Les nouvelles surcharges prennent en charge les quatre formats tar (Pax, Ustar, GNU et V7) pour assurer la compatibilité avec des outils et environnements spécifiques.

D’autres évolutions

La seconde version préliminaire de .NET 11 comprend d’autres évolutions. Ainsi, grâce aux aux améliorations apportées aux performances d'ASP.NET Core, l'analyseur de requêtes HTTP/1.1 de Kestrel utilise désormais un chemin d'exécution qui ne génère pas d'exception pour traiter les requêtes mal formées. Au lieu de lever une exception BadHttpRequestException à chaque échec d'analyse, l'analyseur renvoie une structure de résultat indiquant un état de réussite, d'incomplétude ou d'erreur. Dans les scénarios comportant de nombreuses requêtes mal formées (tels que le balayage de ports, le trafic malveillant ou les clients mal configurés), cela supprime la charge importante liée à la gestion des exceptions tout en améliorant le débit de 20 % à 40 %. Le traitement des requêtes valides n'est pas affecté.

Par ailleurs, le langage F# a simplifié les hiérarchies DIM (Default Interface Member). Toujours avec F#, une fonctionnalité en préversion (--langversion:preview) met en cache les résultats de la résolution des surcharges pour les appels de méthode répétés avec les mêmes types d'arguments. Pour le contrôle de carte dans .NET Maui de nouvelles implémentations de TypeConverter pour Location et MapSpan permettent une syntaxe XAML concise pour les coordonnées de carte, évitant ainsi le recours à un balisage x:Arguments verbeux. Toujours dans le framework d’interface utilisateur multiplateforme, TypedBinding et SourceGeneratedBinding sont désormais environ 29 % plus rapides, avec 50 % d’allocation de mémoire en moins par opération de liaison. Enfin, Entity Framework (EF) Core prend en charge la traduction des méthodes LINQ MaxByAsync et MinByAsync ainsi que de leurs équivalents synchrones. Ces méthodes permettent aux développeurs de trouver l'élément présentant la valeur maximale ou minimale pour un sélecteur de clé donné, plutôt que la valeur maximale ou minimale elle-même.