Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Microsoft annonce la fin de .NET Standard, il sera remplacé par .NET 5
    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

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éprouvé
    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 ?

  3. #3
    Membre expert
    Quelqu'un comprend encore la direction que prend .NET ?

    Microsoft est train d'en faire une hydre sans tête !

  4. #4
    Membre éclairé
    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.

  5. #5
    Membre éclairé
    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

  6. #6
    Membre éprouvé
    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

  7. #7
    Nouveau Candidat au Club
    "C for Yourself"

  8. #8
    Membre éprouvé
    Ç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 ?
    Il y a 10 sortes de personnes dans le monde : ceux qui comprennent le binaire et les autres

  9. #9
    Membre à l'essai
    Pour faire du NET
    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.

  10. #10
    Candidat au Club
    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.

  11. #11
    Membre régulier
    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é ?

  12. #12
    Membre habitué
    J'avoue que je suis paumé. J'en étais à développer en .net core 3 l'année dernière quand j'ai appris que le framework n'évoluerait plus, hier je fais une maj j'ai brièvement vu passer qu'il n'y aurait plus de support je crois sur .net core 3 j'ai pas pu bien voir (ma faute j'ai cliqué trop vite). Ce matin un vieux programme en winform je peux plus rajouter de form je suis en train de voir pourquoi... Quand ce n'est pas votre boulot, et uqe c'est juste comme amateur, ce n'est pas évident à suivre je trouve.

    (réglé le problème, les maj de visual studio avaient mis la pagaille)

###raw>template_hook.ano_emploi###