Discussion :

[Hinault Romaric]

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

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 ?

[François DORIN]

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 ?

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 ?

[Hinault Romaric]

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.

[micka132]

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)!

[Torakushi]

Bonjour à tous !

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

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

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 )

[François DORIN]

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

[micka132]

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.

.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.

[Torakushi]

(coucou Android).

Pas gentillll

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

[kilroyFR]

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).

[dfiad77pro]

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.

[kilroyFR]

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.

[freesket]

Pas convaincu. M$ rajoute une couche de plus au mille feuille logiciel.
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).

Heu désolé, mais MS l'a réalisé avec Windows 10 avant tout le monde => OneCore (PC, Serveur, Phone, Console, IOT...) => UWP.
Par contre Andromeda va faire mal effectivement, car la mayonnaise peu prendre rapidement et concurrencer MS puisque toutes les applications Android seront fonctionnelles (ou presque je suppose).

[kilroyFR]

Heu désolé, mais MS l'a réalisé avec Windows 10 avant tout le monde => OneCore (PC, Serveur, Phone, Console, IOT...) => UWP.
Par contre Andromeda va faire mal effectivement, car la mayonnaise peu prendre rapidement et concurrencer MS puisque toutes les applications Android seront fonctionnelles (ou presque je suppose).

Je parle de choses qui marchent et qui sont utilisées. UWP je ne connais personne qui developpe dessus ni ne cherche a faire du multi plateforme avec "windows" (avec le risque de passer des heures a se former etc. pour une plateforme peu suivie - perso j'ai arréte de me jeter dans la moindre derniere techno revolutionnaire Microsoft apres l'echec cuisant WPF/SL).

Par contre Android -> milliers d'applis donc la possibilité de les faire tourner sur un "PC" telles quelles c'est pour moi la promesse non tenue de microsoft (quand ils ont sorti leurs tablettes "windows" qui ont berné nombre d'utilisateurs amateurs (le grand public) qui croyait pouvoir utiliser les applis habituelles PC sur leur tablettes).
Qui n'a pas dans son entourage quelqu'un (famille) qui s'est faite avoir et qui se retrouve aujourd'hui avec du materiel sans logiciel quasiment.

Android ont d'abord innondé le marché avec des terminaux multi-constructeurs pour finalement arrive maintenant a permettre l'utilisation de ces memes applis (que les gens ont l'habitude d'utiliser) sur leur PC. Je trouve finalement qu'ils ont eu une meilleure approche que Microsoft qui a fait tout le contraire (du PC - mobile).
Sauf qu'un mobile tout le monde en a un dans sa poche (tout le monde n'a pas forcement de PC). Du coup objectivement on voit le resultat et on devine la suite.

[bib34690]

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.

[micka132]

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.

[youtpout978]

Je parle de choses qui marchent et qui sont utilisées. UWP je ne connais personne qui developpe dessus ni ne cherche a faire du multi plateforme avec "windows" (avec le risque de passer des heures a se former etc. pour une plateforme peu suivie - perso j'ai arréte de me jeter dans la moindre derniere techno revolutionnaire Microsoft apres l'echec cuisant WPF/SL).

Par contre Android -> milliers d'applis donc la possibilité de les faire tourner sur un "PC" telles quelles c'est pour moi la promesse non tenue de microsoft (quand ils ont sorti leurs tablettes "windows" qui ont berné nombre d'utilisateurs amateurs (le grand public) qui croyait pouvoir utiliser les applis habituelles PC sur leur tablettes).
Qui n'a pas dans son entourage quelqu'un (famille) qui s'est faite avoir et qui se retrouve aujourd'hui avec du materiel sans logiciel quasiment...

Je suis d'accord pour dire que SL est un échec mais WPF ne l'est pas, c'est la technologie phare de Microsoft pour les applis desktop, celle censé remplacer WindowsForms même si certains reste attaché à cette vieille technologie encore maintenue par MS, les entreprises utilisent essentiellement cette techno quand ils veulent une appli de bureau en .Net, après elle est pas autant utilisée qu'a pu l'être à l'époque WindowsForms étant donné qu'avec la montée en puissance du Web ces dernières années les entreprises priviligient les techno Web (Asp.Net) aux technos bureaux même si ça réponds pas à leur besoin (c'est un autre débats).

Pour les tablettes Windows, c'est vrai qu'avec leur appellation tendancieuse, l'amateur non éclairé a pu se faire avoir, ils ont joué un mauvais coup là, tout ça pour avoir des tablettes petit budget en ARM pour concurrencer Android, j'ai pris une tablette X86 pour ma part que j'ai pu passer sur Windows 10 et sur laquelle tourne toute ma ludothèque PC, le seul reproche que je peux lui faire c'est le manque de ram (2GO pour Windows c'est short).

En tout cas je suis ravi de cette techno ayant développer pour Windows Phone/Windows 8 à titre privé (et oui ça existe), me lançant dernièrement sur Xamarin, je suis content de savoir qu'enfin une vrai base commune va être crée entre toutes ces technos (ça peut être chiant de créer des class pour chaque plateforme à chaque fois qu'on veut faire un truc spécifique), parce que les PCL c'est génial mais suivant les versions, les plateformes ciblées on ne peut pas supporter tous les types de projets.

Par contre une question me taraude, la base class library va continuer à exister et être mis à jour ou va-t-elle être remplacée par cette nouvelle couche sans aucune forme de procès? (je pense que la BCL va subsister pendant encore quelques années).

[Issam]

Silverlight n'est pas un échec mais on l'a tué, c'est pas du tout pareil !!!


Même aujourd'hui il reste en avance en terme de facilité de développement surtout pour les applications de type business notamment avec les ria services .

[kilroyFR]

Silverlight est a lui seul l'embleme des années d'errance de M$ pendant lesquelles ils voulaient continuer les applis desktop (base WPF dont les principes ont ete 'vous jetez tout ce que vous avez appris pour le dev et vous recommencez de zero + databinding + evenementiel + dependancy property = logiciels tres difficile a deboguer) et a la fois faire miroiter aux developpeurs que leur appli WPF/SL pourrait fonctionner sur un navigateur (via plugin bien sur).

Alors sur le papier ca sent deja le truc foireux, du client lourd qui a la couleur du client leger (mais quand pour acceder au moindre fichier local il faut commencer a deployer des certificats sur les postes on se rend compte que deja ca va pas etre simple et qu'on va y passer du temps - c'est du vecu malheureusement).
Alors on se dit que finalement avec tous les frameworks IHM Javascript puissants il est peut etre temps d'arreter ces conneries de WPF/SL bridées sur materiel microsoft et faire du vrai client leger qui donne au moins l'impression de faire quelque chose de multi plateformes et pas une techno bridée deja dès la conception car coincée entre des contradictions.
En tout cas c'est ce qu'on a fait dans notre boite et heureusement; les malheureux developpements WPF/SL restants sont des boulets pour ceux qui les maintiennent (sortie en 2006 - deja obsolete en 2012 !).
Etonnamment on n'a pas ce soucis avec les devpt WinForms qui reste pour moi quelque chose qui aurait du etre poursuivi car ca avait une certaine coherence avec .net et le passage de MFC vers C#/.net.
Quelle idée ont ils eu chez Microsoft de reinventer la roue carrée plutot que de finir le travail commencé !?

[youtpout978]

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.

[kilroyFR]

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.

Ma colere vis a vis de WPF/SL provient de plusieurs gros projet dans ma boite qui nous ont couté enormement en formation/essuyage de platres/problemes deploiement/complexité maintenabilité.
Oui, MVVM aussi on a essayé pour au final revenir a des choses certainement plus maintenables par quiconque.
On a pourtant embauché plusieurs "experts" WPF mais le resultat et l'energie deployée pour faire pas grand chose est considerable comparativement a la meme chose en winforms (genre fonctions de rotation vectoriel d'une icone pour lui faire une rotation ... ou comment utiliser la masse pour enfoncer un clou).
On laisse ces ex-technos merveilleuses aux autres - on y a laissé trop de plumes.
Tres difficile de trouver des experts de ces technos et pour l'avoir vecu, les gains en temps de developpements n'est pas un bon indicateur. Je prefere 10 personnes qui maitrise parfaitement une techno accessible, plutot que "de se faire plaisir" avec une soi disant techno revolutionnaire dont la maitrise reste a demontrer - en tout cas n'a pas fait ses preuves sur tous nos projets (nos experts WPF ecrivent des articles dans Codeproject donc sont censés maitriser cette techno).

Au bout de 7 ans, la seule chose que l'on peut recuperer de ces applis apres passage version web, c'est la couche metier+BDD. Toute la partie IHM = poubelle; refaite en HTML/JS tres rapidement avec les frameworks js existants.

C'est mon retour d'experience (et celui de ma boite) qui fait qu'on a desormais completement abandonné ces technos pour notre plus grand bien.
Ca ne te plait peut etre pas ce que je dis mais c'est la realité de qu'on a vecu sur ces projets. Nos applis pures desktop sont desormais en QT pour pleins de raisons (performances/portabilité etc).