Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Bill Fassinou

142PARTAGES

3  0 
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 ?

Qu'en pensez-vous ?

Voir aussi

.NET Standard : une couche de base unique pour toutes les applications .NET, y compris Xamarin. Microsoft dévoile le futur de sa plateforme

.Net Standard 2.0 est disponible en version finale, avec plus de 30 000 API et une compatibilité avec les packages NuGet ciblant le Framework .Net

Microsoft annonce que UWP prendra en charge .NET Standard 2.0 et met à la disposition des développeurs plus de vingt mille API

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de redcurve
Membre éclairé https://www.developpez.com
Le 19/09/2020 à 10:26
Citation Envoyé par sergio_is_back Voir le message
Quelqu'un comprend encore la direction que prend .NET ?

Microsoft est train d'en faire une hydre sans tête !
C'est assez simple à comprendre.

.NET Framework : framework legacy qui ne recevra plus jamais de nouvelles fonctionnalités
.Net Core : ré-implementation complète de ISO/IEC 23270/23271, ECMA334 etc.
.Net Standard: Spécification formelle d'api sets permettant de partage du code entre les deux le temps que

.NET 5+ : Unification de .NET CorecClr, Xamarin, Mono etc. dépasse complètement le framework legacy comme comme prévu depuis des années le mot "Core" est supprimé n'ayant plus lieu d'être.

En gros .Net Framework est mort
3  0 
Avatar de Aurelien145
Candidat au Club https://www.developpez.com
Le 25/09/2020 à 7:36
Dois je comprendre qu'il y a un nouveau truc, compromis (donc bancal) entre .NETcore et le .NET historique, et que des choses comme winform sont abandonnées ?
Winform n'est pas abandonné https://github.com/dotnet/winforms
Ce n'est pas un compromis. Le principe de .Net standard était de données des niveaux de compatibilité pour ceux qui voudrais développez de nouvelles versions de Net. Et sa reste toujours le cas:
Unity target .Net standard 2.1 et continueras jusqu'as au moins 2022.
Net Framework target .Net standard 2.0 et continueras infiniment
Mono target .Net standard 2.1.(Bien que inclus dans .Net5 peut exister dans des version séparer comme Unity)
.Net 5 et futur target .Net standard 2.1

Comme dis dans le blog officiel si vous développez une librairie et que vous ne sentez pas le besoin de fonctionnalité de .Net5 alors le mieux c'est de ciblé .NetStandard 2.0 ou 2.1 comme sa plus de gens pourrons l'utiliser. Et .NetStandard normalement n'as était fait que pour des librairie donc concrétement sa ne change rien. Le titre est juste la pour attirer du public mais n'est en aucun cas vraix. Il faut lire l'article aussi.

Rappel de la source https://devblogs.microsoft.com/dotne...-net-standard/

.NET 5+ : Unification de .NET CorecClr, Xamarin, Mono etc. dépasse complètement le framework legacy comme comme prévu depuis des années le mot "Core" est supprimé n'ayant plus lieu d'être.
C'était le plan initial. A cause du Covid certaine partie on était repousser à .Net 6.

En gros .Net Framework est mort
.Net standard existe pour deux choses. Aider la migration .Net Framework > .Net Core en proposant au Developeur de librairie une solution pour target les deux. Le but aujourd'hui est justement d'encourager les dévelloppeur à garder des paquage pour .Net Framework.
Pour ce qui on des doute je rapelle que temps que windows utiliseras .Net Framework le support ne s'arréteras pas et aujourd'hui .Net Framework est support jusqu'a aprés 2030... Sa comprend aussi des techno comme WebForm.

Microsoft est train d'en faire une hydre sans tête !
La .net team est en train de faire One.Net sans mettre à la rue les applications/Librairy qui existe sinon ils aurais juste debagger NetStandard et .NetFramework. Ils font de leur mieux pour assurer la compatibilité des applications au dela du support commun. Je rappelle que le support dans l'open source est souvent de 3 ans. C'est le cas avec tout les framework Javascript et aussi le cas avec .Net core. Mais .Net framework as un support qui est plus ou moins infini car liée à Windows. Et ils essaye de faire cohabiter les deux. Si vous avez une meilleure solution personnes ne vous interdit d'en discuter sur Github.
Aprés avec la concurence grandissante il est dur de supporter .Net framework. Car il faut toujours évoluer plus vite.
1  0 
Avatar de epsilon68
Membre éprouvé https://www.developpez.com
Le 19/09/2020 à 5:02
bah moi j'essaie de passer mes libs au .net standard 2.0 pour preparer le passage au .net core voire .net 5, tout en fonctionnant pour le moment au .net 4.7.2

et mince, ils arretent .net standard ... bon pour le moment pas le choix ... ca serait pas de la marche forcée par hasard ?
0  0 
Avatar de sergio_is_back
Membre expert https://www.developpez.com
Le 19/09/2020 à 9:50
Quelqu'un comprend encore la direction que prend .NET ?

Microsoft est train d'en faire une hydre sans tête !
0  0 
Avatar de redcurve
Membre éclairé https://www.developpez.com
Le 19/09/2020 à 10:04
Citation Envoyé par epsilon68 Voir le message
bah moi j'essaie de passer mes libs au .net standard 2.0 pour preparer le passage au .net core voire .net 5, tout en fonctionnant pour le moment au .net 4.7.2

et mince, ils arretent .net standard ... bon pour le moment pas le choix ... ca serait pas de la marche forcée par hasard ?
.net standard n'a jamais été prévu pour durer, de deux .net standard ne correspond à aucune sorte de code c'est juste une définition formelle d'un api set.
0  0 
Avatar de epsilon68
Membre éprouvé https://www.developpez.com
Le 20/09/2020 à 17:17
Citation Envoyé par redcurve Voir le message
.net standard n'a jamais été prévu pour durer, de deux .net standard ne correspond à aucune sorte de code c'est juste une définition formelle d'un api set.
oui et pourtant c'est difficile de passer les libs en standard 2.0 pour migrer l'ensemble vers .net core ou .net 5
0  0 
Avatar de Valdis
Nouveau Candidat au Club https://www.developpez.com
Le 21/09/2020 à 16:06
"C for Yourself"
0  0 
Avatar de petitours
Membre éprouvé https://www.developpez.com
Le 24/09/2020 à 18:22
Ça fait presque 20 ans que j'arrive à peu près à suivre mais là j'ai perdu le fil...

Dois je comprendre qu'il y a un nouveau truc, compromis (donc bancal) entre .NETcore et le .NET historique, et que des choses comme winform sont abandonnées ?
0  0 
Avatar de alexvb6
Membre à l'essai https://www.developpez.com
Le 25/09/2020 à 2:16
Le nommage du produit est mal choisi, puisque .NET permet de cibler des tas de système hors du web.
Néanmoins, lorsqu'il s'est agi de passer de VBScript et ASP Classic à .NET, mon choix a été vite fait !
l'ASP Classic est impressionant en vitesse et sécurité. Ok, les tableaux à 2 dimensions sont un peu pénibles, mais ça reste vraiment très efficace et performant.
0  0 
Avatar de ReiKiss
Membre régulier https://www.developpez.com
Le 29/09/2020 à 11:38
Que devient UWP dans tout ça ? Car cibler un projet avec .Net Standard 2.0 permettait de partager le projet entre des applications .net Core 3.0 et UWP.
Déjà que le support de .Net standard 2.1 est toujours par connu pour UWP, faut’ il comprendre que UWP va être discrètement mis de côté ?
0  0