NOUVELLES DE L'INDUSTRIE

.NET 11 Preview 1 : de grandes avancées pour le runtime, mais des questions plus importantes quant à l'orientation

Mis à jour:

Microsoft a publié la première version préliminaire de .NET 11 en février, apportant des améliorations au niveau de l'exécution. Notre équipe chez Iron Software a examiné la première version préliminaire de .NET 11, et quelques changements méritent d'être soulignés pour la communauté des développeurs .NET .

TL;DR

  • L'asynchrone s'intègre à l'exécution : plus rapide, plus optimisé et plus facile à déboguer. Bonne nouvelle pour nos produits universels.
  • CoreCLR prend désormais en charge WASM et remplace Mono ; le code .NET compilé pour navigateur devrait donc s'exécuter sensiblement plus rapidement.
  • Compression Zstandard native - nous envisageons de l'adopter en interne dans IronZIP.

Microsoft a officiellement publié .NET 11 Preview 1, la première étape du cycle de développement de la prochaine version à support standard, prévue pour novembre 2026.

Asynchronisme au niveau de l'exécution : un changement majeur et discret

L'une des nouveautés les plus importantes de la préversion 1 est que le suivi asynchrone est désormais intégré plus profondément dans l'environnement d'exécution lui-même, au lieu d'être entièrement géré par le compilateur.

Pour rappel, la programmation asynchrone est le modèle qui permet aux applications d'exécuter des tâches par blocs non bloquants, de sorte que le thread entier ne se bloque pas en attendant un appel réseau, la lecture d'un fichier ou une réponse d'une base de données. C'est un élément fondamental du développement .NET moderne. La plupart des API, services et charges de travail pilotées par l'interface utilisateur en dépendent fortement.

En rapprochant la coordination asynchrone de la couche d'exécution, Microsoft peut résoudre ces deux problèmes simultanément :

Débogage : Reconstruction des flux asynchrones. Le débogueur devrait enfin pouvoir retracer les chemins d'exécution entre les instructions await, restaurant ainsi le contexte actuellement perdu.

Performances : réduction des coûts de coordination. L'optimisation au niveau de l'exécution peut être plus poussée que les seules machines à états générées par le compilateur, ce qui réduit le coût par tâche.

Pour les services distribués, les API natives du cloud et les applications d'interface utilisateur, cela pourrait se traduire par des améliorations mesurables sur l'ensemble du spectre.

CoreCLR arrive sur WebAssembly

Jusqu'à présent, les applications .NET compilées en WebAssembly s'appuyaient sur Mono, l'ancien environnement d'exécution conçu à l'origine pour la compatibilité multiplateforme. Mono fonctionne, mais il présente des limites de performance bien connues et ne bénéficie pas des mêmes investissements en matière d'optimisation que CoreCLR.

Avec cette préversion, CoreCLR bénéficie de la prise en charge de WebAssembly, ce qui apporte plusieurs améliorations concrètes : les capacités JIT améliorent la vitesse d'exécution. La gestion de la mémoire devient plus efficace. Les applications .NET hébergées dans le navigateur se rapprochent de plus en plus de l'exécution native. Pour les équipes qui développent des applications Blazor WebAssembly ou qui expérimentent avec des charges de travail .NET côté navigateur, il s'agit de l'une des meilleures mises à jour de toute la préversion.

Cela a également une incidence sur l'écosystème dans son ensemble. Bibliothèques et outils ciblant WASM, notamment le traitement, le rendu et la manipulation de données de documents basés sur un navigateur.

Compression Zstandard native

.NET 11 ajoute une prise en charge de premier ordre de l'algorithme de compression Zstandard (Zstd) grâce à une nouvelle implémentation ZstandardStream. Zstd est devenu un standard dans les systèmes hautes performances car il offre de meilleurs taux de compression que Gzip, une décompression nettement plus rapide et un débit élevé pour le traitement de données à grande échelle.

Pour les développeurs de bibliothèques et d'outils, cela élimine les obstacles liés aux liaisons tierces. Les produits nécessitant une compression importante peuvent désormais utiliser Zstd nativement. On imagine aisément comment cela pourrait s'avérer utile en interne pour des outils comme IronZIP ou des flux de travail similaires où la performance et la taille des fichiers sont toutes deux essentielles.

Thème principal : Le virage de .NET vers l'IA agentive

Au-delà des améliorations apportées à l'exécution, l'orientation stratégique de .NET 11 se précise. Microsoft mise beaucoup sur ce qu'elle appelle " l'IA agentique ", des applications conçues pour interagir avec des agents d'IA, des flux de travail Copilot et des contextes de modèles structurés. Cela inclut la prise en charge du protocole MCP (Model Context Protocol), des modèles de développement assistés par l'IA et des frameworks positionnant les applications .NET comme des outils que les agents peuvent invoquer et orchestrer.

Cette orientation n'est pas surprenante. L'ensemble du secteur évolue vers des flux de travail assistés par l'IA, et Microsoft a tout intérêt à faire de .NET un acteur de premier plan dans cet écosystème.

Ce qui compte vraiment ici

Si l'on met de côté les débats sur la feuille de route et que l'on se concentre uniquement sur l'impact pratique, les améliorations en termes de temps d'exécution constituent la véritable information :

  • Le débogage asynchrone pourrait enfin devenir gérable pour les bases de code complexes.
    Les performances de WebAssembly pourraient s'améliorer sensiblement avec le remplacement de Mono par CoreCLR.
  • La compression Zstd bénéficie désormais d'une prise en charge de premier ordre, éliminant ainsi les dépendances tierces.

Ce ne sont pas des fonctionnalités tape-à-l'œil. Ils ne susciteront pas d'applaudissements lors des conférences plénières. Mais ce sont des améliorations qui réduisent discrètement les frictions dans le développement quotidien, et celles-ci ont tendance à compter bien plus que les fonctionnalités phares sur le long terme.

L'aperçu 1 montre déjà deux facettes de l'écosystème .NET : des progrès importants et significatifs au niveau de l'environnement d'exécution, ainsi qu'une discussion croissante sur l'orientation du langage et les priorités de la plateforme. Cette tension n'est pas forcément une mauvaise chose. Cela signifie généralement que la plateforme évolue de manière à intéresser réellement les gens.