Microsoft annonce la fin de .NET Standard, sa couche de base unique pour toutes les applications .NET, y compris Xamarin

Il sera remplacé par .NET 5

Le 18 septembre 2020 à 11:45, par Bill Fassinou

369PARTAGES

Immo Landwerth de Microsoft a annoncé mardi que la société ne fournira plus une nouvelle version de .NET Standard. Il sera à l’avenir remplacé par .NET 5. Cet abandon est dû à trois problèmes selon Microsoft, notamment la lenteur dans la livraison de nouvelles versions, il a besoin d'un anneau décodeur et il expose des caractéristiques spécifiques à une plateforme donnée. Cela dit, .NET Standard n’est pas totalement mort, car, Landwerth a déclaré que, même s’il va être remplacé par .NET 5, les développeurs l’utiliseront toujours dans certains cas.

.NET Standard est une spécification formelle des API .NET destinées à être disponibles sur toutes les implémentations .NET. L’objectif de la firme avec .NET Standard est d'établir une plus grande uniformité dans l'écosystème .NET. Autrement dit, .NET Standard est l’unique bibliothèque de classes de base qui est utilisée par .NET Framework, .NET Core et Xamarin. Ainsi, un développeur qui crée une API qui cible .NET Standard, peut l'exécuter sur toutes les plateformes .NET. Mais désormais, Microsoft ne fournira plus de nouvelle version de .NET Standard.

« .NET 5 sera un produit unique doté d'un ensemble uniforme de capacités et d'API pouvant être utilisé pour les applications de bureau Windows, les applications mobiles multiplateformes, les applications pour consoles, les services en nuage et les sites Web », annonce l’entreprise. À travers cette annonce, Microsoft est en train de dire aux développeurs qu’à l’avenir, ils devraient se concentrer sur .NET 5, que Microsoft désigne avec le nom de code TFM. Il a déclaré que .NET 5 améliore le partage de code et remplace .NET Standard, sauf dans quelques cas.

Cela comprend les cas où les développeurs doivent étendre la portée de leur partage de code pour prendre en charge des frameworks plus anciens à l’instar de .NET Framework ou partager du code entre des frameworks spécifiques existants. Pour cela, Microsoft a déclaré que .NET 5 et toutes les versions futures continueront à prendre en charge .NET Standard 2.1 et les versions antérieures. L’entreprise demande de considérer net5.0 (et les versions futures) comme la base du partage du code pour aller de l'avant. .NET 5 peut être vu comme la version vNext de .NET Standard.

Les raisons évoquées par Microsoft et qui ont motivé ce changement

Dans son billet de blogue, Landwerth a énuméré en tout trois problèmes connus pour la plateforme .NET Standard. Le premier est que les versions de .NET Standard se succèdent lentement. Le but derrière .NET Standard était d'unifier l'ensemble des fonctionnalités de la bibliothèque de classe de base (BCL). .NET Standard devait vous permettre d’écrire une seule bibliothèque qui puisse fonctionner partout, ce qui a été un succès selon Microsoft. .NET Standard est supporté par plus de 77 % des 1000 premiers paquets. Et dans le cas de NuGet.org, l'adoption est de 58 %.

Mais Landwerth estime que la normalisation de l'ensemble des API a créé une taxe. Il a déclaré que cela nécessite une coordination chaque fois que l’équipe ajoute de nouvelles API, ce qui arrive tout le temps. Par ailleurs, la communauté open source de .NET (qui comprend l'équipe .NET) continue d'innover dans la BCL. Et d’après lui, si l’équipe peut fournir de nouveaux types sous forme de paquets NuGet, elle ne peut pas fournir de nouvelles API sur des types existants ainsi. Donc, au sens général, l'innovation dans le BCL nécessite l'envoi d'une nouvelle version de .NET Standard.

Selon lui, jusqu'à .NET Standard 2.0, ce n'était pas vraiment un problème, car l’équipe ne faisions que standardiser les API existantes. Mais à partir de .NET Standard 2.1, elle a normalisé de toutes nouvelles API et c'est à ce moment qu’elle a vu qu’il y avait pas mal de frictions au sein de l’équipe. Le second problème quant à lui concerne le fait que .NET Standard a besoin d’un anneau décodeur. Séparer l'ensemble des API de leur mise en œuvre ne fait pas que ralentir la disponibilité des API. Cela signifie également que l’équipe doit adapter les versions de .NET Standard à leur mise en œuvre.

Ainsi, Landwerth a déclaré que l’équipe ne peut pas résoudre ce problème sans fusionner certains rectangles dans le diagramme de couches, ce que fait .NET 5. Selon lui, .NET 5 fournit une implémentation unifiée où toutes les parties construisent sur la même base et obtiennent ainsi la même forme d'API et le même numéro de version. Enfin, le dernier problème est en rapport avec le fait que .NET Standard expose les API spécifiques à une plateforme. Selon lui, quand .NET Standard a été conçu, l’équipe a dû faire des concessions pragmatiques pour ne pas trop casser l'écosystème de la bibliothèque.

En d'autres mots, elle a dû inclure certaines API réservées à Windows (telles que les ACL des systèmes de fichiers, le registre, WMI, etc.). Landwerth a déclaré qu’à l'avenir, l’équipe évitera d'ajouter des API spécifiques à une plateforme à net5.0, à net6.0 et aux versions futures. Toutefois, il a précisé que cette tâche est difficile à faire. Par exemple, avec Blazor WebAssembly, l’équipe a récemment ajouté un nouvel environnement où s'exécute .NET et où certaines des API autrement multiplateformes ne peuvent pas être prises en charge dans la sandbox du navigateur.

Beaucoup de développeurs se sont plaints que ce type d'API ressemble à des “mines terrestres”. Le code se compile sans erreur et semble donc être portable sur n'importe quelle plateforme, mais quand on l’exécute sur une plateforme qui n'a pas d'implémentation pour l'API donnée, vous obtenez des erreurs d'exécution. Avec .NET 5, l’équipe fournira des analyseurs et des correcteurs de code avec le SDK qui est activé par défaut. Cela inclut l'analyseur de compatibilité de plateforme. Il détecte l'utilisation fortuite d'API qui ne sont pas prises en charge sur les plateformes sur lesquelles vous avez l'intention de vous exécuter. Cette fonction remplace le paquet Microsoft.DotNet.Analyzers.Compatibility NuGet.

Quel est l’impact de changement sur le code existant ?

Quant à la question de savoir si vous deviez continuer à utiliser .NET Standard 2.0 ou passer directement au .NET 5, Landwerth a répondu que cela dépendait du contexte dans lequel vous vous trouvez, qui sont au nombre de deux :

Composants de l'application

Si vous utilisez des bibliothèques pour décomposer votre application en plusieurs composants, il recommande d'utiliser netX.Y, où X.Y est le plus petit nombre de .NET que votre application cible. Par souci de simplicité, vous souhaitez probablement que tous les projets qui composent votre application soient sur la même version de .NET, car cela signifie que vous pouvez assumer les mêmes caractéristiques BCL partout.

Bibliothèques réutilisables

Si vous créez des bibliothèques réutilisables que vous prévoyez d'expédier sur NuGet, vous devrez envisager un compromis entre la portée et les fonctionnalités disponibles. NET Standard 2.0 est la version la plus élevée de .NET Standard qui est prise en charge par .NET Framework, elle vous donnera donc la plus grande portée, tout en vous offrant un ensemble de fonctionnalités assez large pour travailler. L’équipe déconseille de cibler .NET Standard 1.x, car cela ne vaut plus la peine de s'en préoccuper. Si vous ne voulez pas supporter .NET Framework, vous pouvez opter pour .NET Standard 2.1 ou .NET 5.

La plupart des codes peuvent probablement sauter .NET Standard 2.1 et passer directement à .NET 5. En gros, la prise en charge de .NET Standard 2.0 vous donne la plus grande portée, mais la prise en charge de .NET 5 vous permet d'exploiter les dernières fonctionnalités de la plateforme pour les clients qui sont déjà sous .NET 5. Dans quelques années, le choix des bibliothèques réutilisables ne portera plus que sur le numéro de version de netX.Y, ce qui correspond en gros à la façon dont la création de bibliothèques pour .NET a toujours fonctionné.

Source : Microsoft

Et vous ?