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 !

.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

10PARTAGES

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

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

Avatar de François DORIN
Expert éminent sénior 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 ?
2  0 
Avatar de 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.
1  0 
Avatar de bib34690
Membre habitué https://www.developpez.com
Le 29/09/2016 à 15:34
Je partage l'avis de ceux qui sont mécontents et des autres...
Excité, forcément, toutes ces promesses ça fait rêver et MS a toujours été à la base de grosses innovations alors on se surprend à y croire à nouveau, surtout après qq années d'errance durant lesquelles ont ne savait plus comment programmer.
Mécontent, forcément, si on est fidèle à MS depuis des années : pas de visibilité, des choix incompréhensibles, des trahisons, des technos superbes mais pas au point et abandonnées dès qu'elles commencent à l'être, une complexité croissante qui fait qu'il est impossible de recruter un programmeur MS expérimenté et non dépressif... MS c'est le meilleur et le pire.
MS n'est plus celui qu'il a été. Ses solutions font rêver mais le rêve ça ne rapporte pas. On a besoin d'un minimum de stabilité.
Nous sommes éditeurs. Quand nous investissons sur un projet, c'est pas pour 5 ans. Notre investissement Winform a été bien amorti, celui sur SL a été un crève cœur, ce qui nous est présenté ici fait plus office de vitrine que de techno mature sur laquelle on peut investir, et j'ai peur que la suite ne se répète.
J'adore C#, je ne veut plus développer avec un autre langage, mais devoir tout réécrire tous les 5 ans n'est pas possible pour nous.
1  0 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 29/09/2016 à 18:15
Citation Envoyé par bib34690 Voir le message

MS n'est plus celui qu'il a été. Ses solutions font rêver mais le rêve ça ne rapporte pas. On a besoin d'un minimum de stabilité.
C'est peut être la stabilité induise par Microsoft (par forcement .Net, mais le modèle PC-Windows) que nous regrettons aujourd'hui.
Android n'est pas plus stable, bien au contraire avec leurs fragmentations de plus plus grande. Sans oublier les dizaines de services que Google "a offert" par le passé et fermé du jour au lendemain.
Il n'y a guère plus de stabilité a chercher du coté de Google.
Ce qui embête tout le monde c'est d’être forcé de développer pour IOS et android, tout en continuant de maintenir les applications lob sur PC parce qu’on se rend bien compte qu'on est vachement limité sur une tablette/smartphone.
C'est impossible sur le long terme, et donc les solutions visant à unifier tout ce b***** sont les bienvenues, sauf que ça n'a rien de trivial et pendant ce temps on rame, on sait pas qu'elle solution va rester dans le temps...
Bref une période bien délicate ou il n'y a pas 36 solutions: Se lancer dans une solution quitte à s'en mordre les doigts, faire l'autruche quitte a ne pas être à la page, tout tester en faisant péter les budgets et risquer de s'épuiser.
1  0 
Avatar de youtpout978
Membre expert https://www.developpez.com
Le 30/09/2016 à 11:59
kilroyFr je ne sais pas d'où vient ta haine pour WPF/SL mais le fonctionnement du XAML et les possibilités qu'il offre avec le databinding et autres est une avancée énorme dans le développement desktop, WindowsForms est une techno du passé même si encore maintenue, quand tu maîtrise les 2 plateformes tu te rend compte du gain de productivité et de la légèreté de ton code en passant de WindowsForms à WPF, après il faut accepter le changement de paradigme et favoriser MVVM avec WPF, certes ça demande un temps d'apprentissage mais au grand jamais je ne veux revenir sur WindowsForms, les derniers projets sur lesquels j'ai bossé sur cette techno m'ont paru lour et lent dans la réalisation quand on sait à quel vitesse on fait ça en WPF.

Après WPF n'est pas parfait, le xaml étant une sorte de langage les bugs intervenant dessus ne sont toujours pas compréhensible mais depuis sa création c'est quand même devenu plus facile de trouver la source de son erreur (visual studio indique souvent la ligne en erreur), le plus gros problème c'est surtout quand le xaml se complexifie un peu et que le rendu n'est plus disponible sous visual studio (des bugs similaire existe sur WinForms), ça nous oblige à coder à l'aveugle et d’exécuter le projet pour voir le résultat (avec l'expérience on arrive à savoir ce que ça génère).

La transition peut être dur entre ces 2 technos, moi même je crachais sur WPF la première fois que j'en ai fait en stage la techno venait de sortir, ayant fait que du WinForms je ne comprenait pas qu'on ne codait pas de la même façon, résultat je pondais du code dégeux pour faire la même chose qu'en WinForms, c'est parce que je n'avais pas compris le concept de binding (et autre joyeuseté inhérent à WPF), mais grâce à une formation et les tutos du site dvp.com j'ai pu m'améliorer et enfin exploiter toute la puissance de WPF, c'est là qu'on se rend compte que notre vision était biaisé.

Même si tu ne fais plus de WPF/SL today, rien n'est perdu le MVVM (si tu as fait du MVVM avec WPF) est très utilisé notamment en WEB avec Angular par exemple, le xaml s'est recyclé sur les UWP ou même Xamarin Forms, et de toute façon WPF continue de subsister pour les applications de bureau, surtout pour celles ayant un certain besoin de performance au niveau du rendu.
1  0 
Avatar de 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.
0  0 
Avatar de micka132
Expert confirmé 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)!
0  0 
Avatar de 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 )
0  0 
Avatar de François DORIN
Expert éminent sénior 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
0  0 
Avatar de micka132
Expert confirmé 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.
0  0