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

Le , par Hinault Romaric, Responsable .NET
Que pensez-vous de l’orientation de Microsoft avec .NET Standard ?
Microsoft, depuis plusieurs mois, a adopté une stratégie d’ouverture. Une orientation dans laquelle la firme ambitionne de rendre sa plateforme de développement (.NET) multiplateforme.

L’un des résultats de cette ouverture a été la sortie en juin dernier de la première version stable de .NET Core.

Pour rappel, .NET Core est une version modulaire et épurée du .NET Framework, pouvant s'exécuter sur plusieurs environnements. Avec .NET Core il est possible de créer et déployer des applications .NET sur Windows, Linux et OS X.

.NET Core apporte un début de solution au développement multiplateforme avec .NET. Une solution qui demeure toutefois partielle, car la réutilisation du code reste cependant limitée par la fragmentation qui existe encore dans l'écosystème .NET, entre le Framework .NET, .NET Core et Xamarin.

En effet, même si le même langage de programmation, le même environnement de développement, les mêmes outils de compilation peuvent être utilisés pour ces trois plateformes, chacune dispose de sa propre librairie de base :

  • Base Class Library pour le Framework .NET ;
  • Core Library pour .NET Core ;
  • Mono Class Library pour Xamarin.



Ainsi, tout développeur qui veut écrire du code qui va fonctionner sur les trois plateformes, se voit obligé de prendre en compte et gérer trois bibliothèques de classes de base différentes.

Pour résoudre ce problème, Microsoft dévoile .NET Standard 2.0. .NET Standard sera l’unique bibliothèque de classes de base utilisée par .NET Framework, .NET Core et Xamarin. De ce fait, un développeur qui crée une API qui cible .NET Standard, peut l'exécuter sur toutes les plateformes .NET.





La mise en place de .NET Standard introduit cependant de nombreux défis que Microsoft devra résoudre. Microsoft fait savoir que la solution sera compatible uniquement avec le Framework .NET 4.6.1 et les versions futures.

Toutefois, pour maintenir la compatibilité avec .NET Framework 4.6.1, la firme se trouve dans l’obligation de supprimer les APIs qui ont été introduites dans .NET Standard 1.5 et 1.6.


Par ailleurs, la firme envisage de mettre à jour Xamarin pour prendre en charge l’ensemble des APIs qui seront incluses dans .NET Standard.

Selon Microsoft, .NET Standard 2.0 sera un ensemble d’APIs qui sont actuellement incluses à la fois dans le Framework .NET et Xamarin. Ce qui implique leur extension à .NET Core.

Pour y parvenir, Microsoft envisage étiqueter les APIs du .NET Framework et de Xamarin :

  • Les APIs avec l'étiquette [Requise] seront celles qui sont nécessaires sur toutes les plateformes. Elles seront incluses dans .NET Standard ;
  • Les APIs avec l'étiquette [Optionnelle] seront celles qui sont spécifiques à chaque plateforme. Elles seront disponibles via des packages NuGet.


Ci-dessous les APIs qui seront offertes par .NET Standard 2.0 :



Les outils permettant de cibler .NET Standard 2.0 seront disponibles la même période que la version stable de Visual Studio 15. .NET Standard sera publié comme un package NuGet et bénéficiera d’un support de premier niveau sur Visual Studio, Visual Studio Code et Xamarin Studio.

Pour le futur, Microsoft recommande aux développeurs qui font le développement multiplateforme de désormais utiliser .NET Standard au lieu des “Portable Class Libraries”.

Source : Blogs MSDN

Et vous ?

Que pensez-vous de l’orientation de Microsoft avec .NET Standard ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de François DORIN François DORIN - Responsable .NET & Magazine https://www.developpez.com
le 28/09/2016 à 13:38
Citation Envoyé par Hinault Romaric Voir le message

Ci-dessous les APIs qui seront offertes par .NET Standard 2.0.
Je crois qu'il manque une partie du message. Une petite image peut-être ?

Citation Envoyé par Hinault Romaric Voir le message
Que pensez-vous de l’orientation de Microsoft avec .NET Standard ?
Je pense que c'est effectivement une très bonne chose d'avoir une seule et même bibliothèque de base, qui soit indépendante de la plateforme. Par exemple, cela permettra de réaliser une couche métier portable (et donc partageable !) entre plusieurs plateformes.

Bien entendu, la bibliothèque de base aura ses limites. Par exemple, je vois mal tout ce qui est gestion graphique inclue dedans. Les environnements ciblés sont tellement diversifiés que cela est impossible à l'heure actuelle (d'autant plus que certaines plateformes sont indépendantes de Microsoft).

Reste à savoir aussi si les API optionnelles le seront à la compilation ou à l'exécution. Ce que j'entends par là, c'est, est-ce que pour utiliser une API optionnelle, il faudra inclure un package Nuget, et dès lors, il sera disponible pour la plateforme ciblée au moment de la compilation (et si le package n'existe pas pour la plateforme ciblée alors l'API n'est tout simplement pas utilisable), ou est-ce qu'il faudra utiliser un package Nuget "générique", et c'est au moment de l'exécution que l'on devra vérifier la disponibilité des API ?
Avatar de Hinault Romaric Hinault Romaric - Responsable .NET https://www.developpez.com
le 28/09/2016 à 14:54
Citation Envoyé par dorinf Voir le message
Je crois qu'il manque une partie du message. Une petite image peut-être ?
La news n'etait pas encore complète. Je croyais l'avoir marqué invisible . J'avais un bus à prendre.
Avatar de micka132 micka132 - Membre expert https://www.developpez.com
le 28/09/2016 à 15:31
Je pensais que .Net Core devait déjà faire ce rôle et que ce dernier devait remplacer à terme .Net classique et Mono (Xamarin).
Pourquoi donc l'avoir créer?
Pendant ce temps en entreprise on te demande toujours du winform, du asp.net (non mvc)!
Avatar de Torakushi Torakushi - Futur Membre du Club https://www.developpez.com
le 28/09/2016 à 16:39
Bonjour à tous !

Tout d'abord article très intéressant !

Citation Envoyé par micka132 Voir le message

Je pensais que .Net Core devait déjà faire ce rôle et que ce dernier devait remplacer à terme .Net classique et Mono (Xamarin).
Pourquoi donc l'avoir créer?
Ah j'ai du manquer quelque chose ! Pour moi .NET CORE avait plus pour vocation la portabilité (pour des systèmes à "capacité" limitée) qu'autre choses !
Mais je peux me tromper et je demande qu'à apprendre

Donc je rejoins dorinf sur le fait que c'est un pas de géant de microsoft dans le monde du multi-plateformes

Citation Envoyé par micka132 Voir le message

Pendant ce temps en entreprise on te demande toujours du winform, du asp.net (non mvc)!
JE suis d'autant plus heureux que l'on me demande d'utiliser le WPF MVVM au quotidien alors

Je trouve cela d'autant plus intéressant que j'avais des difficultés à utiliser .NET a la fois sur mon PC linux et sur mon window (portabilité) et que je voulais étudier le xamarin plus profondément (on finit sur une dimension plus égoiste )
Avatar de François DORIN François DORIN - Responsable .NET & Magazine https://www.developpez.com
le 28/09/2016 à 17:02
Je pense qu'il faut reprendre un peu les différentes techno dans leur contexte.

Xamarin, avant d'être racheté par Microsoft, avait pour objectif de permettre de développer avec un seul langage (C#) des applications pour iOS, Android et Windows Phone. Attention, j'ai bien dis un seul langage, pas une seule fois ! L'objectif était de ne pas avoir à utiliser du Java ou de l'Objective-C. Mais ensuite, les API disponibles étaient celles de la plateforme ciblée (même si Xamarin fournissait un framework de base commun à toutes les plateformes, mais qui ne comprenait pas l'IHM ou l'accès aux différentes fonctionnalités du smartphone).

.Net Core avait pour objectif de porter l'infrastructure .Net sur d'autres plateformes, notamment Linux et MacOS (et Windows of course !).

Tout cela, bien évidement, en plus de l'environnement .Net "classique" disponible sous Windows.

Bref, 3 environnements, donc 3 framework.

L'objectif de .Net Standard, est de devenir le socle commun de tous les autres frameworks, et faire également en sorte que les fonctionnalités redondantes (=présentes dans chaque framework) soit définies au niveau de .Net Standard au lieu d'être définies plusieurs fois... Enfin c'est mon interprétation
Avatar de micka132 micka132 - Membre expert https://www.developpez.com
le 28/09/2016 à 17:05
Citation Envoyé par Torakushi Voir le message
Ah j'ai du manquer quelque chose ! Pour moi .NET CORE avait plus pour vocation la portabilité (pour des systèmes à "capacité" limitée) qu'autre choses !
Mais je peux me tromper et je demande qu'à apprendre
C'était mon interprétation, erroné semble t-il .
Je pensais qu'il était destiné à remplacer .Net parce que créer une fragmentation est une merde sans nom sur le long terme (coucou Android).
Au lieu de sortir un autre nom qui va englober tout ça, ils auraient pu directement attribuer ce rôle a .Net Core.

Citation Envoyé par dorinf Voir le message
.Net Core avait pour objectif de porter l'infrastructure .Net sur d'autres plateformes, notamment Linux et MacOS (et Windows of course !).
C'est ce que j'ai du mal à comprendre, si c'est seulement ca .Net est déjà prévu pour, il suffit en gros d’implémenter la machine virtuelle sur l'OS cible, comme Mono le fait.

Bref c'est une confusion supplémentaire car on ne sait pas si au final .Net, Core, Mono vont disparaître et s'il faut cesser de s’intéresser à eux.
Avatar de Torakushi Torakushi - Futur Membre du Club https://www.developpez.com
le 28/09/2016 à 17:42
Citation Envoyé par micka132 Voir le message
(coucou Android).
Pas gentillll

Citation Envoyé par micka132 Voir le message

C'est ce que j'ai du mal à comprendre, si c'est seulement ca .Net est déjà prévu pour, il suffit en gros d’implémenter la machine virtuelle sur l'OS cible, comme Mono le fait.
Pour moi .NET CORE a aussi une dimension de "légereté" : il y a le meme GC et JIT que .NET framework un runtime plus petit construit de la meme manière que .NET framework CLR mais il y a des services non présents ( Code Access Security, ... ) . Il y a une librairie de "base" codé de la meme facon que pour le .NET mais "factorisé" avec moins de dépendances (des projets moins lourds) ; et c'est à la charge du développeur de rajouter "à la main" les dll externes.

Je me doute que je dois me tromper ou oublier certains points et je cache pas que je suis comme toi, je ne connais pas vraiment .NET CORE Donc si on peut nous expliquer ce que c'est exactement
Avatar de kilroyFR kilroyFR - Membre confirmé https://www.developpez.com
le 28/09/2016 à 22:28
Pas convaincu. M$ rajoute une couche de plus au mille feuille logiciel.

L'impression que M$ refait le travail qui a ete fait a l'epoque sur Mono cad le portage des API .net (sauf les IHMS car c'est le plus complique - d'ailleurs cette partie n'est pas listée dans .net standard).
Donc on arrivera rapidement a quelque chose qui va atteindre ses limites. J'avais cru comprendre egalement que c'etait le but de .net Core (qui ne fait pas grand chose comparé a ce qu'il est permis de faire avec le framework .net sur PC).
J'aurai prefere que M$ se focalise sur .net Core et l'enrichisse plutot que de partir sur un nouveau sujet (nouvelle api) de plus.

M$ me desespere pour tout dire. Ca donne l'impression d'une roadmap coherente mais elle me parait bien compliquée pour la cible.
Je n'envisagerai pas de mettre en prod un logiciel basé sur une telle architecture. Perso je ne vais pas me lancer la dedans et attendre 1 an ou 2 pour voir ce que ca donne.
.net Core/.net standard ... beaucoup de semantique...

D'autant qu'en 2016 on parle de plus en plus a revenir a du devpt natif (C++) pour les perfs sur ces environnements hybrides (perso j'ai developpé plusieurs applis entreprise sur Android/java et je suis en train de basculer sur NDK pour ameliorer les perfs - eviter le vol du code (desassemblage etc)).
Ca n'aurait pas ete plus simple de finaliser mono et l'etendre a ios/android (ca tombe bien c'est une base linux) ?

Avec Andromeda ca s'annonce compliqué pour M$ pour faire face a ce qui s'annonce (l'environnement PC/Mobile universel qu'ils n'ont jamais ete capables de realiser).
Avatar de dfiad77pro dfiad77pro - Membre expérimenté https://www.developpez.com
le 29/09/2016 à 0:33
Citation Envoyé par kilroyFR Voir le message
Pas convaincu. M$ rajoute une couche de plus au mille feuille logiciel.

L'impression que M$ refait le travail qui a ete fait a l'epoque sur Mono cad le portage des API .net (sauf les IHMS car c'est le plus complique - d'ailleurs cette partie n'est pas listée dans .net standard).
Donc on arrivera rapidement a quelque chose qui va atteindre ses limites. J'avais cru comprendre egalement que c'etait le but de .net Core (qui ne fait pas grand chose comparé a ce qu'il est permis de faire avec le framework .net sur PC).
J'aurai prefere que M$ se focalise sur .net Core et l'enrichisse plutot que de partir sur un nouveau sujet (nouvelle api) de plus.

M$ me desespere pour tout dire. Ca donne l'impression d'une roadmap coherente mais elle me parait bien compliquée pour la cible.
Je n'envisagerai pas de mettre en prod un logiciel basé sur une telle architecture. Perso je ne vais pas me lancer la dedans et attendre 1 an ou 2 pour voir ce que ca donne.
.net Core/.net standard ... beaucoup de semantique...

D'autant qu'en 2016 on parle de plus en plus a revenir a du devpt natif (C++) pour les perfs sur ces environnements hybrides (perso j'ai developpé plusieurs applis entreprise sur Android/java et je suis en train de basculer sur NDK pour ameliorer les perfs - eviter le vol du code (desassemblage etc)).
Ca n'aurait pas ete plus simple de finaliser mono et l'etendre a ios/android (ca tombe bien c'est une base linux) ?

Avec Andromeda ca s'annonce compliqué pour M$ pour faire face a ce qui s'annonce (l'environnement PC/Mobile universel qu'ils n'ont jamais ete capables de realiser).

C'est pas très objectif déjà quand ça commence par du M$, c'est sûr Google s'en fous des Dollars et travail de manière entièrement bénévole

- .net standard ne remet pas en cause les habitude dev, il unifie sans casser. Pour mono, on ne parle pas de tout casser, on unifie les librairies de bases qui sont déjà au dessus de la CLR...
- .net core est réputé très performant coté WEB
- si tu offusque ton code en le passant en C++, c'est sous-estimer les hackeurs.
- En plus j'ai pas trop l'impression que la mode soit à l'optimisation en ce moment (ils préfèrent acheter des serveurs et ne pas trop optimiser, car l'optimisation coute plus cher )
- D'autre part des outils comme .net native permettent en partie de réduire ce gap de performance.

Bref relis un peu plus attentivement l'article, tu comprendras rapidement pourquoi on unifie tout à partir de la 4.6.1 et que le soit disant cassage des api n'est pas vraiment problématique dans les faits.
Avatar de kilroyFR kilroyFR - Membre confirmé https://www.developpez.com
le 29/09/2016 à 10:05
M$, io$ etc. whatever je ne suis fanboy de personne - juste simple constatation de ce qui marche a l'instant t et ce qui ne prend plus; je laisse ce genre de gamineries a d'autres.

Ce qui est objectif c'est mon retour sur les technos M$.
30 ans que je travaille avec du M$ donc j'ai un peu d'experience (coder de l'asmx86 C/C++/ASPnet/JScript etc - C# v6 en passant par les tres mauvais WPF/SL etc.) + accessoirement Xenix-Linux donc je n'ai aucun partie pris ni jugement sur les langages/technos. Chacun a ses plus et ses moins.
Je desespere juste des errements de M$ ces dernieres années (essuyer les echecs WPF/SL ca laisse forcement des traces et de la rancune) et du coup attendre un peu de laisser les autres passer devant pour voir si c'est un investissement (en temps/formation etc) utile ou pas.
Il y a 20 ans on foncait tete baissée car il n'y avait que peu de fournisseur de solutions. En 2016 c'est plethore et M$ n'est malheureusement plus le lievre mais plutot le suiveur.

Quand je parle de repasser en C++ au lieu d'une inutile obfuscation ce n'est pas pour se proteger des hackers (qui eux savent lire de l'assembleur) mais plutot pour proteger un peu le logiciel de copie de code entier
(autre ex : eviter de se voir envoyer des sources corrigés de logiciels (du vecu d'un client c'est pour ca que j'en parle). Quand tu recois ton code en clair avec l'endroit a corriger et que c'est le client qui te le founit, certes ca rend humble.
Responsables bénévoles de la rubrique Microsoft DotNET : Hinault Romaric - François DORIN -