L'écosystème .Net est en pleine mutation. À l’occasion de la publication de la première Release Candidate de sa version 5.0, l'éditeur est revenu sur les problèmes rencontrés, évoquant l'avenir de son framework, répondant à de nombreuses question. Notamment tout ce qui touche à .Net Standard.

La technologie .NET a parcouru bien du chemin depuis son introduction en février 2002. Elle se voulait une approche unifiée du développement pour les plateformes Microsoft et le web, faisant la part belle à C#. Depuis, le périmètre a très largement évolué, au point que la société a voulu se recentrer avec .NET Core.

L'accent prononcé sur le multiplateforme ces dernières années a mis en lumière de nombreux problèmes dans la manière dont la construction avait été envisagée. C’est particulièrement vrai pour .NET Standard, qui désigne le lot d’API dont l’implémentation a été validée pour l’ensemble des systèmes supportés.

Aujourd’hui, le modèle prévu est « condamné » : il sera bientôt remplacé par .NET 5.0, tout aussi multiplateforme, sorte d’aboutissement de ce qu’avait en tête Microsoft au départ. Mais il aura fallu des années pour que l’éditeur tâte le terrain, puis change brusquement d’orientation sous l’impulsion des objectifs fixés par Satya Nadella.

• Télécharger .NET 5.0 Release Candidate 1

Qu’est-ce que .NET Standard ?

Avant de plonger sur les raisons qui ont poussé Microsoft à revoir profondément ses plans, commençons par un rappel des différentes déclinaisons de .NET à l'heure actuelle, en commençant par .NET Standard.

Il s’agit d’une spécification, conçue pour accompagner .NET Core, jouant le rôle de plus petit dénominateur commun pour les projets multiplateformes. Même si .NET Core est lui-même un cadriciel (framework) multiplateforme, les développeurs ont la possibilité de lui adjoindre nombre de paquets pour en augmenter la portée.

.NET Standard était un vrai progrès, puisque les développeurs pouvaient s’y référer pour s’assurer que leurs projets fonctionneraient autant sur Windows que Linux ou macOS, en établissant un socle isofonctionnel. Quand la version 2.0 est sortie en septembre 2017 par exemple, elle était compatible avec .NET Framework 4.6.1, .NET Core 2.0, Mono 5.4, Xamarin iOS 10.14, Xamarin.Mac 3.8 et Xamarin.Android 7.5.

Cette version 2.0 ajoutait la bagatelle de 32 000 API dans le pot commun, d’où son importance. À ce moment-là cependant, le travail était encore « facile », car il s’agissait alors d’implémenter des API existantes. Les problèmes se sont manifestés avec la mouture 2.1, qui s’aventurait sur de nouvelles API.

Les problèmes de .NET Standard

L’une des principales barrières à l’évolution de Standard était l’absence de convergence des plateformes .NET au niveau de l’implémentation. Standard représentait la spécification, mais l’implémentation elle-même pouvait être différente. Conséquence, ajouter une nouvelle API engendrait un intense travail de coordination entre les équipes.

C’est d’autant plus devenu un problème que .NET Core est un projet open source, avec une communauté active ayant largement contribué à développer la BCL (Base Class Library). Devant ce foisonnement, un conseil était chargé de vérifier les nouveautés et de les intégrer si elles étaient implémentées dans au moins une plateforme.

Ce travail a réclamé du temps, trop pour que .NET Standard puisse évoluer à un rythme soutenu. Selon Microsoft, toute API manquant le coche d’une version aurait attendu au moins deux ans pour la suite. En outre, les développeurs auraient dû attendre que l’implémentation suive et se retrouve sur assez de plateformes pour se servir des nouvelles capacités.

L’éditeur se moque volontiers de lui-même et de ces idées qui pouvaient sembler initialement simples. Il passait son temps à créer finalement des piles sous-jacentes pour unifier l’ensemble des API. Le but fut atteint avec .NET Standard, mais qui n’était qu’une spécification, ne corrigeant finalement qu’une partie du problème.

Autre idée qui se voulait au départ pragmatique et a donné de mauvais résultats : l’inclusion d’API spécifiques à des plateformes. Microsoft ne voulait pas faire exploser l’écosystème des bibliothèques et a imaginé cette solution pour permettre une transition douce. Mais il est devenu complexe de prévoir le comportement des API ajoutées par la suite, dans des cas comme Blazor WebAssembly, où une partie des interfaces multiplateformes ne pouvaient pas fonctionner dans la sandbox du navigateur.

Les développeurs ont a priori été nombreux à faire des retours négatifs sur ce point, évoquant des « champs de mine ». Le code était en effet compilé correctement et donnait ainsi l’impression qu’il pouvait fonctionner sur les autres plateformes… pour finalement générer des erreurs.

.NET 5.0 et les futures évolutions annuelles

.NET 5.0 est donc un aboutissement, ou du moins la première étape de l’aboutissement. D’une part, il n’y aura plus d’un côté le framework classique (actuellement en version 4.8.1) et .NET Core, mais un seul environnement. D’autre part – et c’est sans doute le plus important – les spécifications et leur implémentation seront réunies au même endroit. En clair, NET 5.0 est une base de code unique pour tous les développements.

Il n’y aura donc plus aucune nouvelle version de .NET Standard. .NET 5.0 est d’ailleurs compatible avec toutes les versions passées de la spécification. Un développeur peut donc sans problème installer le nouveau cadriciel et continuer à viser la version 2.1 de Standard par exemple. Vu par Microsoft, .NET 5.0 et les versions ultérieures continueront le travail de Standard, mais avec une base de code unique et un rythme plus soutenu.

Maintenant que la Release Candidate est là, on attend donc la version finale, prévue pour novembre. Le rythme est d’ailleurs prévu : une nouvelle mouture majeure de .NET tous les ans, une version sur deux étant LTS (Long Term Support). .NET 6.0 sortira ainsi en novembre 2021 et sera une mouture LTS. 

Des versions spécifiques supplémentaires en 2021

Notez que des versions spécifiques sortiront ensuite. Les développeurs pourront ainsi choisir entre une application multiplateforme et un projet visant un système, avec à la clé des API dédiées et donc plus de capacités.

Au départ, ce choix sera limité : .NET 5.0 ne proposera en plus du socle commun qu’une version Windows. Elle contiendra notamment tout ce qui touche à WinForms et WPF, soit à la conception des interfaces sur le système maison et qui n'a rien à faire dans la base commune. À compter de .NET 6.0 en revanche, des versions Android et iOS seront proposées. Une version macOS a de bonnes chances d’être prête également.

Qu’en est-il de Linux ? La situation est plus complexe. En clair, Linux en tant que plateforme « n’est pas bien défini ». Le noyau l’est, mais les développeurs n’en seront pas plus avancés dans le cadre d’un framework touchant aux éléments d’interface notamment. La situation est sous surveillance et pourrait changer. En attendant, .NET 5.0 et les versions ultérieures seront bien disponibles sous Linux, mais sans spécificités.

La nomenclature évolue également pour plus de clarté. Tous les TFN (Target Framework Names) auront désormais la forme netX.Y, à laquelle viendra éventuellement s’ajouter un tiret puis le nom de la plateforme. Par exemple, la version initiale de .NET 5.0 s’appellera net5.0, et celle pour Windows net5.0-windows. Quand les moutures Android et iOS sortiront l’année prochaine, on pourra les viser respectivement via net6.0-android et net6.0-ios. La future version pour macOS devrait être logiquement nommée net6.0-macos.

Que doivent faire les développeurs de leurs applications face à .NET 5.0 ? La situation peut être résumée ainsi :

• Utiliser netstandard2.0 en cas de code partagé entre .NET Framework (l’ancien ) et les autres plateformes
• Utiliser netstandard2.1 en cas de code partagé .NET Core 3.x, Mono et Xamarin
• Utiliser net5.0 dans les autres cas

D’ailleurs, ce n’est pas parce que .NET 5.0 arrivera que les développeurs auront à prendre rapidement une décision. La question ne se pose que pour le retargeting, par exemple s’ils souhaitent tirer parti des apports de .NET 5.0.

Dans un prochain article, nous nous pencherons sur les évolutions de C# et les nouvelles orientations que Microsoft donne à son langage fétiche.