Winforms vs. WPF

Hello,

Je savais pas trop si je devais poster ceci dans le forum Winforms ou WPF alors je poste dans le forum général .NET.

Là où je travaille (un petit service informatique d'une chaine de magasin de prêt à porter), mon chef vient de me poser une question à laquelle je ne savais pas trop quoi répondre...
Actuellement nous développons en Winforms et développons uniquement pour des besoins interne à l'entreprise.

La question est de savoir pendant combien de temps cette technologie sera encore maintenue/disponible.

Peut-on rester sur Winforms ?
Faut-il envisager de migrer vers WPF à moyen terme ?
Faut-il plutôt sauter WPF pour passer directement à WinRT afin deviser Windows10 et sa plate-forme unique ? (si j'ai bien compris)
Quid des développements pour mobile (nous sommes justement en train de migrer la flotte mobile vers du Windows Phone donc ça va venir) ? Quelle techno choisir pour cela ?

J'ai bien tenté quelques recherches sur le net mais, soit je ne trouve pas l'info qui m'intéresse, soit elle date de plusieurs années et est donc probablement obsolète...
C'est pourquoi je me tourne vers vous. Nulle doute que certains d'entre vous ont déjà toutes les réponses à ces question.

Merci d'avance à ceux qui prendront le temps de participer à la discussion.

P.S. : Les réponses dogmatiques du genre "il faut choisir WPF parce que c'est mieux" ne m'intéressent pas.

Bonjour,

je vais essayer de répondre le mieux possible :

Citation:

---

Peut-on rester sur Winforms ?

---

Lors de tes recherches t'as du tombé sur un paquet de "WPF c'est l'avenir , Winforms en a plus pour longtemps". Malheureusement , ce n'est toujours pas le cas (et c'est loin d'être le cas).

Pourquoi ?

Bonne question. Mais en voyant ce sondage datant de 2008 , il y a peut être un début de réponse :

http://www.componentfactory.com/blog...es/Survey4.gif

Est-ce que les développeurs sont toujours frileux ? Je ne sais pas.

Personnellement je suis toujours sur WinForms et j'arrive a faire de belles choses et j'ai un peu la flemme de passer de l'un a l'autre car c'est assez différent et repartir de zéro ,bof.

Pourtant WPF a d'indéniables qualités. Le fait que ça soit vectoriel est un gros plus , et des contrôles propres a WPF qui sont très utiles. J'en ai même parlé a un autre développeur qui commençait en C# et qui était tatillon comme moi sur l'interface , il n'envisage même plus de faire du Winforms.

Je pense que WPF souffre d'un coté gadget , car il apporte surtout de l’esthétisme , chose qu'un développeur lambda se fout royalement, surtout s'il maîtrise déjà Winforms.

Pour finir , oui tu peux très bien rester sur Winforms , il a encore de beaux jours devant lui.

Citation:

---

Faut-il envisager de migrer vers WPF à moyen terme ?

---

Question de goûts je dirai. Si vous voulez faire une refonte total de l'UI pour une application plus attractif ,pourquoi pas ?

Citation:

---

Faut-il plutôt sauter WPF pour passer directement à WinRT afin deviser Windows10 et sa plate-forme unique ? (si j'ai bien compris)

---

Bonne question , ce qu'ils ont dit avec Windows 10 et leur système de plateforme unique est très séduisant.

http://dev.windows.com/en-us/develop...l-Windows-apps

Je pense que c'est a surveiller de près.

Citation:

---

Quid des développements pour mobile (nous sommes justement en train de migrer la flotte mobile vers du Windows Phone donc ça va venir) ? Quelle techno choisir pour cela ?

---

Windows Phone utilise Silverlight , qui utilises du XAML aussi et qui est donc assez proche de WPF.

Différences entre Silverlight et WPF

Bonjour Kropernic,
C'est un très bon sujet, et ce sont de bonnes questions intéressantes, je vais essayer d'y répondre le mieux...

Citation:

---

Envoyé par Kropernic

La question est de savoir pendant combien de temps cette technologie sera encore maintenue/disponible.
Peut-on rester sur Winforms ?

---

Aussi longtemps que les APIs des couches Windows existeront sur les futures versions de Windows, aussi longtemps Winforms sera maintenu. Winforms fait partie intégrante du Framework.NET depuis le début et s'appuie sur les DLLs des couches Windows telles que "user32.dll", "shell32.dll", "gdi32.dll", "kernel32.dll", etc, etc... Si Microsoft choisit de ne plus maintenir Windows, ça voudra dire que l'OS aura radicalement changé au niveau du noyau (où sera sur le point de changer radicalement) et dans ce cas, plus aucune application "desktop" ne serait maintenue non plus.

Citation:

---

Envoyé par Kropernic

Faut-il envisager de migrer vers WPF à moyen terme ?

---

J'ai pratiqué un peu le WPF pour des projets perso et je m'y suis assez bien fait. Je ne connaissais que le winforms moi aussi avant et de mon expérience je peux dire qu'il y a des choses plus simples et d'autres plus compliquées.
Si tu veux par exemple faire en sorte à ce que la partie "logique/métier" soit assez indépendante de la partie purement IHM, c'est plus simple en WPF qu'en Winforms (le databinding en winforms peut être assez prise de tête). Il y a aussi certains traitements "graphiques" plus faciles. Par exemple, dans ma société précédente, on avait effectué un module en winforms pour faire un petit système de cartographie pour des repérages. Eh bien on s'est pris très fort la tête pour gérer les zoom. Avec WPF, cela aurait été beaucoup plus simple grâce aux "Viewbox".

Parmi les choses qui me plaisent bien en WPF, il y a notamment la notion de "Commande" où tu définis qu'est ce qui se passe sur l'exécution de la commande et dans quelles conditions elle n'est pas disponible : cela permet que la commande ne soit pas trop fortement associée juste à un bouton mais à plusieurs points d'accès différents de l'IHM (par exemple un bouton et un menu sont associés à une même commande).

Parmi les inconvénients de WPF, on peut citer le fait que l'on ne retrouve pas tous les composants qui étaient disponibles avec winforms. Je pense que cela vient du fait que WPF était aussi bien ciblé pour Windows que pour Silverlight... Et puis quand on définit des styles, cela peut finir par devenir vraiment très technique : on peut faire plein de choses mais plus on "customize" et plus il faut vraiment bien connaître les mécanismes sous-jacents (et il y en a pas mal).

Citation:

---

Envoyé par Kropernic

Faut-il plutôt sauter WPF pour passer directement à WinRT afin deviser Windows10 et sa plate-forme unique ? (si j'ai bien compris)

---

Ce que j'ai compris, c'est que WPF serait toujours disponible à l'avenir (et dans le Framework 4.6 ils ont même fait des évolutions de WPF) et que dans Windows 10 il y aura toujours une partie "bureau" et une partie "winrt"... Après, je pense que si WPF disparait, alors winforms disparait aussi car ce serait pour les mêmes raisons que celles que j'ai évoquées ci-dessus...

Citation:

---

Envoyé par Kropernic

Quid des développements pour mobile (nous sommes justement en train de migrer la flotte mobile vers du Windows Phone donc ça va venir) ? Quelle techno choisir pour cela ?

---

VS 2013 intègre une partie où l'on peut faire des "Applications universelles". Avec 1 seul code, on peut cibler les plateformes winrt et windowsPhone... et avec Xamarin il sera aussi possible de cibler Android et IOS. D'ailleurs, en version gratuite, il y a VS 2013 Community qui est sorti très récemment, et qui intègre la possibilité de faire du ciblage multi-plateformes. Par contre il y a des conditions d'utilisation un tout petit peu plus restrictives qu'avec les versions expresses...

Hello,

Déjà, merci à tous les deux pour vos réponses.

Ce que j'ai retenu jusqu'ici :

• Winforms ne va pas mourir demain donc on est assez à l'aise niveau planning si on décide de migrer.
• Même combat pour WPF mais ce dernier permet de faire des choses plus agréable à regarder (downside : faut apprendre l'xaml)
• Windows 10 permettrait de toujours faire tourner les applications desktop faites avec Winforms/WPF donc pas d'inquiétude

Pour ce qui est des Universal Apps avec VS2013, j'ai la version pro et je ne trouve pas de type de projet permettant de faire cela :-/

Pour ce qui est développement mobile, si je vous ai bien suivi, c'est une application silverlight qu'il faut faire ? N'y a-t-il pas un type de projet spécifique ?

Citation:

---

Envoyé par Kropernic

Pour ce qui est des Universal Apps avec VS2013, j'ai la version pro et je ne trouve pas de type de projet permettant de faire cela :-/

---

Ah bon? C'est curieux, le type de projet est disponible avec les versions express et community, je suis vraiment étonné que ce ne soit pas dispo sur une version pro... Cela dit il me semble (mais je vérifierai quand je serais rentré chez moi) que ce n'est disponible uniquement que si le PC sur lequel VS 2013 est installé a Windows 8.1 comme OS...

Citation:

---

Envoyé par Ph_Gr

Ah bon? C'est curieux, le type de projet est disponible avec les versions express et community, je suis vraiment étonné que ce ne soit pas dispo sur une version pro... Cela dit il me semble (mais je vérifierai quand je serais rentré chez moi) que ce n'est disponible uniquement que si le PC sur lequel VS 2013 est installé a Windows 8.1 comme OS...

---

Je suis effectivement sous Win7.

Le pattern MVVM est vraiment un gros avantage, ce qui permet de dissocier le code de l'interface assez facilement, le Binding assez poussé qui permet de faire des formulaires très rapidement avec une interaction avec la BDD sans trop de code, faire des fenêtres dont les composants se redimensionnent assez facilement (ça peut être une vrai plaie en WinForm de gérer la taille en %), la création de datagrid complètement personnalisé assez facilement (finit le datagrid et ses composants prédéfini), la gestion des événement en bubbling et tunneling qui peut être très utile dans certain cas, tous les composants (même ceux de base) customisable en profondeur et à différent niveau comme en css.

Citation:

---

Envoyé par Kropernic

Je suis effectivement sous Win7.

---

Je confirme : au travail sous VS community je n'avais pas l'option. A la maison sous W8.1 je l'ai :
Pièce jointe 162980

Bonjour,

Citation:

---

Envoyé par Ph_Gr

Bonjour Kropernic,
Aussi longtemps que les APIs des couches Windows existeront sur les futures versions de Windows, aussi longtemps Winforms sera maintenu. Winforms fait partie intégrante du Framework.NET depuis le début et s'appuie sur les DLLs des couches Windows telles que "user32.dll", "shell32.dll", "gdi32.dll", "kernel32.dll", etc, etc... Si Microsoft choisit de ne plus maintenir Windows, ça voudra dire que l'OS aura radicalement changé au niveau du noyau (où sera sur le point de changer radicalement) et dans ce cas, plus aucune application "desktop" ne serait maintenue non plus.

---

C'est sortir un peu beaucoup du sujet, mais je vais donner l'exemple d'Excel. Excel supporte depuis longtemps, si ce n'est pas depuis ses tous débuts, les "macros" au format xll, si tant est que ce sont bien des macros. Ces "macros" sont supposées être écrites en C. Office 2010 les supporte toujours et Microsoft fournissait encore le SDK avec Office 2010. (Pour Office 2013, je ne sais pas.)

Toujours avec Excel, le "Compatibility Pack" d'Office 2010, permet de remonter jusqu'au format Sylk, qui était celui de Multiplan, et même jusqu'à Word 2.

J'ai même vu passer des mises à jour de sécurité pour Silverlight.

Tout ça pour dire que Microsoft a, depuis longtemps, le respect de la compatibilité. Même si elle n'est pas complète entre VB6 et VB.net, il y a quand même un paquet de choses qui ont été maintenues depuis longtemps. Je pense donc que le passé est garant de l'avenir et que ce n'est pas demain la veille que les WindowsForms vont devoir être abandonnées.

Excellent sujet.
Je pense que WPF et Winforms ont une durée de vie similaire en termes de support.
Si "Windows X" devais radicalement revoir la couche desktop et supprimer le support de Winforms alors WPF subirait certainement le même destin.

Nous avons fait le choix il y a 3 ans de passer sous WPF et nous ne le regrettons pas, MVVM peut être contraignant mais reste un avantage, la liste des composants (éditeurs tiers) est plus conséquents, on sort des boutons coloré ^^ et ce peut être un plus pour le marketing, sans oublier Blend qui est magique.
Le problème de performance de WPF a tendance à s'atténuer et aujourd'hui, à partir de Zéro, je prendrais WPF.

Bonjour,

J'ai fait beaucoup de WPF/silverlight/Windows8 et dernièrement j'ai du refaire un peu de Winform. Je vais essayer de te faire mon retour d’expérience. Je parlerais plutôt de techno XAMl que de WPF car pour moi, même s'il y a des différences, elles se résolves facilement avec l'habitude

Citation:

---

Envoyé par Kropernic

Peut-on rester sur Winforms ?

---

Alors de brute en blanc, oui. On peut rester sur Winform, on peut faire de jolie application en Winform (oui c'est possible), en tout cas techniquement rien ne nous en empêche, et tant que les couches graphiques GDI serons supportés, Winform sera supporté, et de nombreux framework/bibliothèques propose des templates à l’aspect graphique moderne.

Citation:

---

Envoyé par Kropernic

Faut-il envisager de migrer vers WPF à moyen terme ?

---

Je vais reprendre l’expérience de mon client actuel, et le pourquoi il ne franchit pas le "pas" XAMl .

Les développeurs ont utilisé Winform pendant plus de 10 ans, pour eux faire une UI en Winform "c'est plus rapide", et puis il y a trop de trucs à apprendre/nouveaux sur XAMl . Et en plus si tu n'as pas un "designer" c'est compliqué de faire des choses jolies.

Pour moi dans leur argumentation, la seule chose valable, est la courbe d'apprentissage pour faire des choses "propres". Mais je dirais en Winform aussi !!!
On peux faire les même choses crades en Winform qu'en XAMl , il n'y a qu'a voir le code de leurs projet, aucune notion de binding, hormis de temps en temps sur des DataGrid et DataTable, tout en code-behind ect....
On peut faire la même chose en WPF, et de la même façon, avec du code behind des events liés aux action, on peut aussi utiliser le designer faire du Drop&Clic ect...

Par contre pour faire quelque chose de propre et découplé c'est beaucoup plus difficile en Winform, et tout naturel en XAMl.

Si on se tourne vers une architecture avec la volonté de s’oriente sur quelque chose de maintenable et évolutif, avec du code métier découplé, sans code behind ou très peu alors oui il faut faire l'effort d'apprendre XAMl . Même si cela reste possible en Winform, l'effort fournit et beaucoup plus grand, et la mécanique lié à la techno atteint vite ses limites.

J'ai fait cet effort dernièrement, on arrive à avoir un code plus ou moins découplé, mais on se retrouve avec les problèmes lié au visuel, bouger un contrôle ou repositionner une page, changer le style faire des effet un peu jolis, modifier un event UI, tout cela est une horreur en winform, alors qu'en XAML avec son langage de description, cela me prends 3min, le plus compliqué étant d'apprendre ce langage. Et encore je ne parle pas de la puissance de son binding, le systeme de DataTemplate des styles ect...

De même, que ce soit en Winform ou en XAML, si on est mauvais en design cela sera aussi moche, et il existe les même style avec les même template dans les deux technos. Et si effectivement un designer venait à être embauché il sera plus facile pour lui ou le développeur de modifier une application existante en XAML.

Du coup le plus gros problème de WPF reste sa courbe d'apprentissage, si le projet est gros, urgent et que tu ne connais pas XAML, reste sur Winform, mais profites en pour mettre en place du binding et un ersatz de MVVM pour te former au moins sur le pattern, et avoir un code métier découplé (maintenabilité), mais aussi pour éventuellement faire évoluer ton application vers une nouvelle techno plus tard.


Pour le reste, d'autres intervenants on parfaitement répondu.

Cordialement.

En effet, la courbe d'apprentissage est le plus gros problème de cette migration je pense.

Sinon, concernant le pattern MVVM, j'avoue que je ne sais même pas ce que c'est.

Mais, malgré que je bosse avec winform, j'ai déjà un code découplé où toutes les couches sont parfaitement séparées et où, sauf si je change un des objets de bases, les changements ne sont qu'à un seul endroit sans impacter les autres couches. Peut-être que je fais du MVVM sans le savoir ^^.

Sinon, ce que je retiens c'est que, à moins de vouloir des applications top glamour avec les dernières couleurs et courbes à la mode, pas la peine de se compliquer la vie à apprendre le WPF.
Car si d'aventure le coeur de windows venait à être modifier pour ne plus supporter GDI+, WPF en serait également affecté.

Donc quitte à faire le pas d'apprendre une nouvelle techno, autant passer directement au cap suivant.

J'ai bien compris ou faut-il que je relise ?

Citation:

---

Envoyé par Kropernic

En effet, la courbe d'apprentissage est le plus gros problème de cette migration je pense.

Sinon, concernant le pattern MVVM, j'avoue que je ne sais même pas ce que c'est.

Mais, malgré que je bosse avec winform, j'ai déjà un code découplé où toutes les couches sont parfaitement séparées et où, sauf si je change un des objets de bases, les changements ne sont qu'à un seul endroit sans impacter les autres couches. Peut-être que je fais du MVVM sans le savoir ^^.

Sinon, ce que je retiens c'est que, à moins de vouloir des applications top glamour avec les dernières couleurs et courbes à la mode, pas la peine de se compliquer la vie à apprendre le WPF.
Car si d'aventure le coeur de windows venait à être modifier pour ne plus supporter GDI+, WPF en serait également affecté.

Donc quitte à faire le pas d'apprendre une nouvelle techno, autant passer directement au cap suivant.

J'ai bien compris ou faut-il que je relise ?

---

Ce que tu fait c'est du développement en couche, normal.

Ce dont je parle c'est surtout du découplage entre metier, "metier visuel" et affichage. rien que le fait de devoir "binder" en code-behind sur Winform, casse le découplage à ce niveau là. Et si jamais tu change de type de contrôle et que son évent possède une signature différente tu es bon pour aller taper du code behind. Sur XAML le fait d'utiliser le binding et le pattern ICommand de façon naturel, n'impacte pas ton code si tu change de type de contrôle, mais juste sa déclaration visuel (XAML), aucunement sa façon d'être lié au mécanisme sous adjacent lié (si c'est bien fait).

Mais c'est normal le designe de l'affichage et son code-behind sont intimement lié en Winform, c'est pour cela que l'on parle plus de "Model-Vue-Présenter" en winform et de "Model-Vue-VueModel" en XAML.

Mais oui tu as bien compris, si tu fait des choses visuellement très simple, cela n'est pas plus compliqué en winform qu'en WPF.
Sur des choses plus jolie, le WPF à l'avantage de loin.
Avantage aussi a XAML pour la refactorisation (que ce soit du style visuel ou du code)

Mais cela est valable si on par du principe que les techno sont bien utilisé, si tu code comme un "goret" en XAML alors ce sera aussi difficile qu'en winform, voir même plus.
Pour exemple j'ai du reprendre entièrement une application développé en windows 8 façon winform pour la faire évoluer, car il fallait tout casser pour pouvoir suivre des deadlines.
Les précédents développeurs n'arrivaient plus à avancer (c'est pour cela qu'on l' a récupéré) car ils ne comprenaientt pas ce qui se passait, avec des effets de bord partout, mais cela était normal. Moi non plus je ne pouvais pas la faire évoluer sans tout casser, et reprendre une architecture "saine". Et pourtant il n'avaient pas implémentés beaucoup de choses, mais le peu était fait sans connaitre la techno, avec des morceaux de tutoriaux pris sur le net, mais rien de cohérent.

Et effectivement je te parle plus de passer le cap vers des techno "XAML", et si on regarde l'actualité Microsoft, il est peut être plus avantageux d'aller voir du coté de Windows8/10.

Tu peux faire du WPF étant donné que WinRT sur 8 et surement sur 10 c'est du XAML, donc ce que tu as appris en WPF n'est pas perdu, et pour avoir testé les 2 tu auras beau penser qu'on peut tout faire sur WinForms si tu boss sérieusement sur WPF tu voudra plus retourner en arrière.

Citation:

---

Envoyé par Kropernic

Sinon, ce que je retiens c'est que, à moins de vouloir des applications top glamour avec les dernières couleurs et courbes à la mode, pas la peine de se compliquer la vie à apprendre le WPF.

[...]

J'ai bien compris ou faut-il que je relise ?

---

Voila c'est ça, on pousse une nouvelle techno juste pour avoir des "boutons de couleurs".

T'as tout compris c'est bon..

Citation:

---

Envoyé par beekeep

Voila c'est ça, on pousse une nouvelle techno juste pour avoir des "boutons de couleurs".

T'as tout compris c'est bon..

---

Je pense que c'était ironique pas la peine de le moinser.

Mais comment ai-je pu passer à côté de ce topic ? :)

Citation:

---

Peut-on rester sur Winforms ?

---

Oui WinForms est une techno riche, mature et très répandue.
Donc si tu n'as pas de besoins particuliers aucun intérêt de passer à WPF.

Citation:

---

Faut-il envisager de migrer vers WPF à moyen terme ?

---

Envisager oui dans le cadre d'une veille technologique pragmatique, mais il y a rarement urgence (cf le 1er point).

Citation:

---

Faut-il plutôt sauter WPF pour passer directement à WinRT afin deviser Windows10 et sa plate-forme unique ? (si j'ai bien compris)

---

WinRT à mon avis absolument aucun intérêt :
- tu veux faire une application LOB sans te fermer de porte ? une seule solution : WPF
(eh oui car ce que le marketing MS oublie parfois c'est que WinRT ce n'est pas disponible sous Windows 7 et XP qui représentent une part considérable du marché, encore plus chez les pros (100% chez quasiment tous mes clients))
- tu veux faire une application légère et l'important c'est la portabilité ? une solution répandue et qui a fait ses preuves : la stack web, sinon si tu as du mal avec la stack web alors Xamarin pour continuer sur des bases C#/.Net
(eh oui WinRT ce n'est que pour Windows qui a une part de marché sur les mobiles lilliputienne (- de 10%))

Donc WinRT c'est bien en interne chez MS pour factoriser leur plomberie Windows entre les différentes versions.
Mais pour les clients finaux IMHO aucun intérêt.

Citation:

---

Quid des développements pour mobile (nous sommes justement en train de migrer la flotte mobile vers du Windows Phone donc ça va venir) ? Quelle techno choisir pour cela ?

---

Pour les vieux mobiles c'est Silverlight for Windows Phone.
Pour les plus récents il y a WinRT mais à oublier car useless (cf point précédent).
Donc le top c'est la stack web : portabilité et accessibilité maximales, mais c'est un autre univers donc ça demande un effort d'adaptation.
Même MS s'y met via Cordova notamment.
Sinon il y a Xamarin qui permet de continuer dans l'environnement familier C#/.Net mais qui n'a bien sûr pas la même portée.

Concernant WPF j'ai compilé tous les faits pertinents quant à sa situation actuelle : Est-ce la fin de WPF: présent et futur de WPF

Full stack web d'accord pour faire de petites appli, mais sur de grosse application ça devient vite le bordel, avec en plus les problèmes de performances que ça peut amener, certain truc pas forcément simple à gérer suivant la techno choisi (l'internationalisation par exemple sur cordova), si on veut utiliser des bibliothèques externes développer en c# faut un boulot pour l'intégrer, mais j'ai vu qu'il est possible d'utiliser razor avec Xamarin ce qui peut être un bon compromis.

Faire à la fois du WinRT et du WPF ça peut être une bonne solution en faisant du MVVM il y a moyen de partager le code entre les 2 plateformes.
De plus je pense qu'avec windows 10 qui est très attendu et qui risque d'être installé sur une pléthore de périphérique, WinRt peut être intéressant pour se faire un peu d'argent sur cette plateforme.

Je dis WinRT parce que je ne connais pas le nom de la techno qui prend sa place sur windows 10.

Citation:

---

Envoyé par youtpout978

Full stack web d'accord pour faire de petites appli, mais sur de grosse application ça devient vite le bordel, avec en plus les problèmes de performances que ça peut amener, certain truc pas forcément simple à gérer suivant la techno choisi (l'internationalisation par exemple sur cordova), si on veut utiliser des bibliothèques externes développer en c# faut un boulot pour l'intégrer, mais j'ai vu qu'il est possible d'utiliser razor avec Xamarin ce qui peut être un bon compromis.

---

La stack web reste en effet plus limitée c'est pour ça que pour le moment pour faire du LOB il faut généralement se tourner vers WPF.
Mais les choses évoluent très vite notamment côté frameworks avec Angular qui va bientôt passer la seconde.

Citation:

---

Envoyé par youtpout978

Faire à la fois du WinRT et du WPF ça peut être une bonne solution en faisant du MVVM il y a moyen de partager le code entre les 2 plateformes.
De plus je pense qu'avec windows 10 qui est très attendu et qui risque d'être installé sur une pléthore de périphérique, WinRt peut être intéressant pour se faire un peu d'argent sur cette plateforme.

Je dis WinRT parce que je ne connais pas le nom de la techno qui prend sa place sur windows 10.

---

Le partage n'est que théorique étant donné le nombre de divergence entre les 2 plateformes, c'est une des choses qui m'a le plus déçu avec WinRT.
Et pour Windows 10 j'espère que WinRT sera toujours là car sinon ça va couiner après toutes les belles promesses sur cette nouvelle plateforme.

J'ai lu un peu en diagonale ce qui a été dit. Par contre j'ai quelques questions de "confirmé".
J'ai appris le VB puis ai passé au C#, le tout en utilisant WinForms et il est certain que lorsqu'on est développeur et qu'on se soucie peu du design WinForms est tout simplement un plaisir.

Néanmoins ce que je cherche est quand même d'actualiser un peu le design de mes applications, faire un effort de présentation du moins. J'ai lu que fondamentalement on peut avoir recours au WPF comme au WinForms (même si on passe a coté du potentiel de la chose), du coup je me pose la question sur la courbe d'apprentissage, si je passe au WPF (connaissant déja le WinForms), j'apprendrais forcément à mieux l'utiliser au fil du temps non ?