Discussion :

[Hinault Romaric]

.NET Core 3.0 offrira un support du développement d’applications de bureau
mais sur Windows uniquement

.NET Core 3.0 offrira une prise en charge du développement d’applications de bureau Windows. C’est ce qui ressort du billet de blog publié récemment par Microsoft.

La conférence Build, la grande messe annuelle des développeurs et professionnels de l’IT, organisé par Microsoft bat son plein actuellement au Washington State Convention Center à Seattle.

La première journée de l’événement a été riche en annonces. L’une des nouvelles clés de la journée pour les développeurs a été l’annonce de ce qui est prévu pour la prochaine version majeure de .NET Core, la plateforme de développement open source de Microsoft.

.NET Core a été développé avec par ses objectifs principaux, l’ouverture à d’autres plateformes, dont Linux et OS X. Pour y parvenir, toutes les technologies du Framework .NET liées à Windows ont été abandonnées.

Mais actuellement, .NET Core n’offre pas de prise en charge de ASP.NET WebForms, Windows Forms et Windows Presentation Foundation (WPF). Microsoft n’avait aucun plan pour le port de ces outils. Cela veut dire que .NET Core est disponible sans prise en charge d’un Framework d’interface utilisateur. Ce qui n’arrange pas de nombreux développeurs, qui ont exprimé leur besoin auprès de Microsoft.

Microsoft a entendu la voix de ceux-ci. La firme a annoncé lors de la Build que sa principale priorité sera la prise la charge du développement d’applications Desktop Windows dans .NET Core 3.0. Il s’agit plus précisément du support de Windows Forms, Windows Presentation Framework (WPF) et UWP XAML.

Les applications de bureau développées avec .NET Core pourront ainsi bénéficier de plusieurs avantages offerts par la plateforme, dont :

• des améliorations de performances et mises à jour du runtine ;
• la facilité de tester une nouvelle version de .NET Core juste sur une application de votre ordinateur ;
• l’activation à la fois du déploiement global et du déploiement local des applications ;
• la prise en charge des outils CLI de .NET Core ;
• l’utilisation du nouveau .csproj et la gestion des packages.

Avec .NET Core 3.0, vous serez en mesure d'exécuter de nouvelles applications de bureau Windows ou des applications existantes sur .NET Core et profiter de tous les avantages de la plateforme. Mais cette nouveauté sera disponible uniquement pour Windows. Le support pour les applications Windows desktop sera ajouté sous la forme d'un ensemble de packages sous le nom de « Windows Desktop Packs ».

Cela dit, l'architecture de .NET Core ne devrait donc pas changer. Microsoft publiera également une nouvelle version de .NET Standard en même temps. Et naturellement, toutes les nouvelles API .NET standard seront incluses dans .NET Core 3.0. Microsoft n'a par exemple pas encore ajouté Span<T> à la norme et compte le faire dans la prochaine version.

Une première préversion de .NET Core 3.0 sera publiée avant la fin de cette année et la version stable devrait être disponible courant 2019.

Source : Blog MSDN

Et vous ?

Comment accueillez-vous la prise en charge du développement d’applications de bureau sur .NET Core 3.0 ?

Voir aussi :

Microsoft annonce la disponibilité de Visual Studio 2017 version 15.7 : un tour d'horizon des nouveautés de l'EDI
Microsoft annonce la disponibilité de .NET Core 2.1 RC1, cette version peut déjà être utilisée en production
Build 2018 : Microsoft annonce la disponibilité en préversion publique de VS Live Share, son extension de développement collaboratif en temps réel

[dfiad77pro]

Dommage pour Linux et IOS.

Mais bon maintenant, il est trop tard pour essayer de porter WPF, il y'aurait fallut le faire avant 2012 à mon avis.


Maintenant on va devoir se coltiner des technos comme Electron qui a le mérite au moins de tourner partout ( et de ne pas casser les API tout les mois #ModeJs).

L'avenir est peut-être coté Xamarin, cependant j'ai l'impression que les technos Microsoft sont boudées et que les devs (ou plutôt les décideurs), semblent plutôt se palucher coté google

[François DORIN]

Si c'est une bonne nouvelle pour pouvoir porter des applications déjà existantes sur .NET Core, je pense que Microsoft se tire une balle dans le pied avec cette approche.

Je m'explique : les développeurs qui demandent à pouvoir faire des applications de bureau le veulent pour avoir un développement portable utilisable sur Windows, Linux et MacOS. Ils ne le font pas pour pouvoir bénéficier des dernières améliorations de .NET Core.

Ici, Microsoft réintroduit un développement spécifique pour Windows (ok, sous forme de pack, mais cela reste du spécifique) au sein de .NET Core.

Est-il possible de porter des technos comme Winform ou WPF sur d'autres plateforme ? Sans doute que oui, mais à quel prix ? Le projet Mono le fait tant bien que mal pour les Winform, et WPF n'a jamais été considéré. Le problème de ces technos c'est qu'elles sont très (trop ?) proche de l'architecture de Windows pour en faire des implémentations portables.

Modifier les implémentations actuelles pour les rendre portables, c'est prendre le risque de créer des incompatibilités entre l'implémentation "historique" et une nouvelle implémentation pour .NET Core.

A mon sens, il est effectivement nécessaire de pouvoir développer des applications de bureau, et que cette possibilité soit incluse directement dans .NET Standard. Il y a bien l'initiative XAML Standard qui va dans ce sens, mais est encore incomplète (et qui ne semble plus évoluer :/) et qui ne spécifie malheureusement pas tout.

[redcurve]

Si c'est une bonne nouvelle pour pouvoir porter des applications déjà existantes sur .NET Core, je pense que Microsoft se tire une balle dans le pied avec cette approche.

Je m'explique : les développeurs qui demandent à pouvoir faire des applications de bureau le veulent pour avoir un développement portable utilisable sur Windows, Linux et MacOS. Ils ne le font pas pour pouvoir bénéficier des dernières améliorations de .NET Core.

Ici, Microsoft réintroduit un développement spécifique pour Windows (ok, sous forme de pack, mais cela reste du spécifique) au sein de .NET Core.

Est-il possible de porter des technos comme Winform ou WPF sur d'autres plateforme ? Sans doute que oui, mais à quel prix ? Le projet Mono le fait tant bien que mal pour les Winform, et WPF n'a jamais été considéré. Le problème de ces technos c'est qu'elles sont très (trop ?) proche de l'architecture de Windows pour en faire des implémentations portables.

Modifier les implémentations actuelles pour les rendre portables, c'est prendre le risque de créer des incompatibilités entre l'implémentation "historique" et une nouvelle implémentation pour .NET Core.

A mon sens, il est effectivement nécessaire de pouvoir développer des applications de bureau, et que cette possibilité soit incluse directement dans .NET Standard. Il y a bien l'initiative XAML Standard qui va dans ce sens, mais est encore incomplète (et qui ne semble plus évoluer :/) et qui ne spécifie malheureusement pas tout.

MS fait converger .net Framework et .net core en mettant tout le code spécifique Windows dans une brique séparé. Pour de la gui multiplateforme faut voir du coté de Xaml standard cette approche est juste logique.


WPF n'a rien de spécifique à Windows, en fait XAML est juste un langage de sérialisation et ne dépend pas de la plateforme en soit

[François DORIN]

MS fait converger .net Framework et .net core en mettant tout le code spécifique Windows dans une brique séparé.

Justement, le problème est là. .NET Core est portable, .NET Framework non. Donc je pense que c'est un mauvais signal que d'afficher clairement la possibilité de faire des applications .NET Core qui ne seront pas portables. Quel avantage dans ce cas de faire du .NET Core par rapport à l'usage du Framework .NET classique ?

Pour de la gui multiplateforme faut voir du coté de Xaml standard cette approche est juste logique.

WPF n'a rien de spécifique à Windows, en fait XAML est juste un langage de sérialisation et ne dépend pas de la plateforme en soit

Attention à ne pas tout confondre. XAML, c'est une représentation en XML d'une interface graphique. L'objectif de XAML standard est d'harmoniser les différents composants de base (bouton, label, textbox, etc.) pour faire en sorte qu'une application de bureau ou mobile par exemple utilise les mêmes bases, et permettent éventuellement de partager le même code XAML d'une plateforme à une autre.

WPF est un framework graphique qui utilise XAML. Si XAML n'a rien de spécifique à Windows (Xamarin Forms l'utilise par exemple), ce n'est pas le cas de WPF qui est très scpécifique à Windows puisqu'il utilise DirectX.

[Pol63]

un peu déçu aussi, j'aurais préféré un "nouveau" framework UI utilisant xaml et portable ...

[dfiad77pro]

Justement, le problème est là. .NET Core est portable, .NET Framework non. Donc je pense que c'est un mauvais signal que d'afficher clairement la possibilité de faire des applications .NET Core qui ne seront pas portables. Quel avantage dans ce cas de faire du .NET Core par rapport à l'usage du Framework .NET classique ?

De pouvoir mettre à jours le Framework .NET pour une appli sans mettre à jours Windows(entendu dans la Keynote d'aujourd'hui)

[François DORIN]

L'idée est intéressante, mais si j'ai bien compris, ces packs ne sont que pour Windows Forms, WPF et UWP. Cela ne représente donc pas le Framework.NET mais un sous-ensemble du Framework .NET.

Mais par contre, effectivement, la mise à jour de .NET Core et/ou des packs sera possible sans devoir mettre à jour Windows. +1 donc

[xarkam]

Il existe http://avaloniaui.net/ pour faire des composant graphiques quelque soit l'os.
Et ca ressemble au wpf.

Ainsi qu'un tout balbutiant https://github.com/VitalElement/AvalonStudio

Donc, l'avenir s'annonce par mal je pense.

[xav-stargate]

Nul comme décision ! Microsoft choisit la facilité ! Le principal intêret de .NET Core c'est d'être multiplateforme, si on ajoute une GUI il faut qu'elle le soit aussi (qu'importe que ça soit via un package ou autre). Si on veut une GUI on utilise WPF et .NET Framework avec une library et .NET Standard ... je ne comprend pas ce choix de la part de Miscrosoft.

[StringBuilder]

A mon avis, l'objectif de Microsoft est simplement de pouvoir abandonner à terme .NET Classique au profit du seul .NET Core.

Le support des WinForms et WebForms est sous forme de "pack" afin :
- Soit de pouvoir être abandonné quand tous les développeurs spécifiques Windows seront passés sur Core
- Soit de pouvoir les porter petit à petit sur d'autres plateformes

Vu les merdes que fait Microsoft depuis quelques années, moi je sens un mélange des deux : une fois que tout le monde sera passé (de force) à .NET Core, WinForms et WebForms seront abandonnés (car ça fait plus de 10 ans que Microsoft essaie de les arrêter sans succès).
A la place, on va récupérer de couches portables basées soit sur du XAML, soit une autre norme quelconque.

Au final, on va fait encore plus d'interprété, des applications HelloWorld qui feront 500 Mo et nécessiteront 16 Go de mémoire pour démarrer, exactement comme Java.

Je suis très franchement déçu par l'ensemble des décisions de Microsoft depuis le développement de WUP, que PERSONNE n'a jamais voulu utiliser. Windows 10 Mobile a été tout simplement sacrifié en essayant d'imposer un Framework boudé des développeurs.
Au lieu de se demander pourquoi les développeurs boudent les nouveaux Framework, Microsoft ferait bien d'arrêter de nous encourager à faire de la merde.
Quand je vois que Visual Studio 2017 propose de faire du AngularJS à grands coups de 400 Mo de dépendences par projet, pour pisser un code qui ne contient plus une seule ligne de .NET je me demande à quand on va avoir un abandon pur et simple de .NET "ouais nan mais finalement on a tous essayé on abandonne". Sentiment de déjà vu...

[redcurve]

A mon avis, l'objectif de Microsoft est simplement de pouvoir abandonner à terme .NET Classique au profit du seul .NET Core.

Le support des WinForms et WebForms est sous forme de "pack" afin :
- Soit de pouvoir être abandonné quand tous les développeurs spécifiques Windows seront passés sur Core
- Soit de pouvoir les porter petit à petit sur d'autres plateformes

Vu les merdes que fait Microsoft depuis quelques années, moi je sens un mélange des deux : une fois que tout le monde sera passé (de force) à .NET Core, WinForms et WebForms seront abandonnés (car ça fait plus de 10 ans que Microsoft essaie de les arrêter sans succès).
A la place, on va récupérer de couches portables basées soit sur du XAML, soit une autre norme quelconque.

Au final, on va fait encore plus d'interprété, des applications HelloWorld qui feront 500 Mo et nécessiteront 16 Go de mémoire pour démarrer, exactement comme Java.

Je suis très franchement déçu par l'ensemble des décisions de Microsoft depuis le développement de WUP, que PERSONNE n'a jamais voulu utiliser. Windows 10 Mobile a été tout simplement sacrifié en essayant d'imposer un Framework boudé des développeurs.
Au lieu de se demander pourquoi les développeurs boudent les nouveaux Framework, Microsoft ferait bien d'arrêter de nous encourager à faire de la merde.
Quand je vois que Visual Studio 2017 propose de faire du AngularJS à grands coups de 400 Mo de dépendences par projet, pour pisser un code qui ne contient plus une seule ligne de .NET je me demande à quand on va avoir un abandon pur et simple de .NET "ouais nan mais finalement on a tous essayé on abandonne". Sentiment de déjà vu...

L'objectif à terme est d'avoir un seul framework portable, et si tu veux faire un truc spécifique windows suffira d’installer le pack windows. Surtout ça permet de résoudre le problème de la dépendance du framework à Windows. De la même façon qu'Asp.net core permet de résoudre le problème de la dépendance à IIS (voir System.Web) qui empêchait de faire évoluer la plateforme sans faire aussi évoluer IIS ... Les deux étant liés comme cul et chemise.

Concernant UWP ça marche très bien et j'en suis content, et je ne vois pas en quoi Microsoft est responsable du bordel concernant les appli web à base de angularJS qu'importe la techno serveur le souci vient des tonnes de modules ayant chacun une tonne de dépendance. Donc si tu as un problème avec ça va voir avec les devs de ces projets. Qu'il faille installer nodejs + gulp + 3 tonnes de fichier json + npm etc. pour déployer un pauvre script JS bah c'est pas la faute à MS il s'agit d'un truc normal même si j'en convient qu'on en arrive à des aberration mais ce sont les devs web qui veulent bosser comme ça ...

WebForm est très loin d'être abandonné il continu d'évoluer ... ce n'est pas parce que asp.net mvc est sorti que webform et mort loin de là webform correspond à un cas précis qui est de faire du RAD et MVC à un autre avoir le controle.

Par contre que MS veuille tuer Winform est une bonne idée, je le rappel winform n'est pas une techno mais juste d'une flat API par dessus celles de windows, en gros ça leur éviterai d'avoir à maintenir 30 tonnes de code pour continuer à faire marcher ce bordel alors qu'il est obsolète à la mort. Surtout que le code sur lequel était mapper WinForm n'existe même plus dans windows (depuis windows vista), heureusement que l'os a tout une api pour faire des hooks.

A titre perso pour du desktop c'est UWP ou WPF suivant le SI du client, pour du web MVC ou du MVCVM facile a faire avec MVC et knockout. Pour du mobile Xamarin Forms souvent, la V3 est tip top.

Je considère WinForm comme ce qu'il est obsolète, dépendant de code n'existant plus et donc nécessitant 30 tonnes de plomberie dans Windows pour tourner depuis 2009... Depuis l'époque c'est WPF et maintenant UWP les deux étant facile à prendre en main, en même temps j'ai commencé à faire du XAML quand WPF étant en bêta 2 ça remonte.

[François DORIN]

L'objectif à terme est d'avoir un seul framework portable, et si tu veux faire un truc spécifique windows suffira d’installer le pack windows. Surtout ça permet de résoudre le problème de la dépendance du framework à Windows. De la même façon qu'Asp.net core permet de résoudre le problème de la dépendance à IIS (voir System.Web) qui empêchait de faire évoluer la plateforme sans faire aussi évoluer IIS ... Les deux étant liés comme cul et chemise.

Sauf que l'approche choisi facilite et encourage de faire du spécifique au lieu du portable.

Par contre que MS veuille tuer Winform est une bonne idée, je le rappel winform n'est pas une techno mais juste d'une flat API par dessus celles de windows, en gros ça leur éviterai d'avoir à maintenir 30 tonnes de code pour continuer à faire marcher ce bordel alors qu'il est obsolète à la mort. Surtout que le code sur lequel était mapper WinForm n'existe même plus dans windows (depuis windows vista), heureusement que l'os a tout une api pour faire des hooks.

Un beau concentré d’âneries en 2 lignes :

• Microsoft n'a pas prévu de tuer Windows Forms ;
• c'est bien une techno à part entière, reposant certes sur une API Windows (GDI), mais qui fournit de nombreuses facilités (des contrôles absents (list/tree view, datagridview, etc), les événements, etc) ;
• la techno sur laquelle repose les WinForm est toujours présente au sein de Windows et n'a absolument pas été retiré avec Windows Vista. Je ne sais absolument pas d'où sort cette ineptie. Si cela avait été le cas, alors la très grande majorité des applications graphiques natives (non managées donc) aurait cessée de fonctionner ;
• s'il était "obsolète à mort", Microsoft ne continuerait pas à le maintenir, en améliorant le support. Dernièrement, une meilleure prise en charge des DPI élevés avec les dernières version du Framework .NET

C'est dommage car le reste du commentaire est intéressant, mais devant un tel bashing basé sur des considérations totalement fausses...

[StringBuilder]

C'est la seconde fois que je lis que WebForms est dépendant de IIS, et notamment System.Web
=> J'aimerais un exemple concret. Jusqu'à présent, Mono permet parfaitement de faire tourner WebForms avec Apache sous Linux.

Idem pour WinForms
En quoi :
- est-ce obsolète ?
- est-ce lié aux API du système ?

A nouveau, Mono sous Linux permet parfaitement de faire tourner des applications WinForms avec autre problème que des dimensionnements de contrôles qui peuvent être différents sous Gnome ou KDE par rapport à Windows. On a accessoirement le même souci quand on active ou désactive le service "themes" sous Windows, qui change notamment les dimensions des menus, bords de fenêtres ainsi que l'aspect des boutons (entre autres).

Mais il ne faut pas prendre le problème à l'envers.
WinForms et WebForms s'arrêtent au code qu'on écrit.
Si ensuite pour dessiner un bouton ou pour gérer les accès aux variables de session Microsoft a sciemment fait le choix d'encapsuler dans sont FrameWork des appels à des API spécifiques de Windows ou de IIS, c'est pas un souci du langage lui-même. Ni même du FrameWork, simplement de la manière dont le FrameWork a été implémenté. Rien n'empêche de modifier WinForms et WebForms pour reposer sur des API plus modernes qui ne soient plus liées à Windows.

La seule chose que je vois comme vraiment obsolète dans WinForms, c'est l'absence d'événements liés aux écrans tactiles, avec notamment la possibilité d'avoir plusieurs zones pressées actuellement.
Et Microsoft a décidé de ne pas les implémenter non pas parce que WinForms ne le permet pas, mais simplement parce que c'est plus facile de pousser WUP en arrêtant de faire évoluer WinForms.

[François DORIN]

C'est la seconde fois que je lis que WebForms est dépendant de IIS, et notamment System.Web
=> J'aimerais un exemple concret. Jusqu'à présent, Mono permet parfaitement de faire tourner WebForms avec Apache sous Linux.

Idem pour WinForms
En quoi :
- est-ce obsolète ?
- est-ce lié aux API du système ?

Ils ne sont pas obsolètes. C'est juste que l'implémentation actuelle de WebForms et WinForms est très liées à l'architecture sous-jacente (IIS pour WebForms, GDI pour WinForms). Porter ces deux technologies nécessite donc un travail important de réécriture (ce que fait le projet Mono).

Si ces deux technos avaient été prévu pour être portable dès le début, il aurait été beaucoup plus facile de les concevoir d'une manière beaucoup plus modulaire, et isolant le code spécifique à une plateforme plutôt qu'en l'éparpillant comme c'est le cas à l'heure actuelle.

Pour en revenir aux WebForms, l'espace de noms System.Web expose de nombreuses fonctionnalités liées à IIS. Je pense notamment :

• à la gestion du cache ;
• à la gestion du processus hébergeant (l'application pool) ;
• à la gestion des sessions.

Il y a certainement d'autres points, mais cela fait bien longtemps que j'ai arrêté WebForms au profit de MVC, donc je suis un peu "rouillé".

[xarkam]

Winforms n'est pas abandonné (rétro compatibilité oblige notamment)

Mais, Ms, préconise de développer en wpf plutot que winforms.

Le soucis qu'a eu wpf, c'est une lenteur de "dessin" vis à vis de winform, lorsqu'il est sorti.

Nous sommes en 2018, wpf est devenu complet et n'est plus lent.

Par exemple, un programme wpf est plus rapide à se dessiner qu'une app dans electron. Pourtant wpf reste incompris.

Le fait de porter winform et wpf sur net core a du sens.
Je fait une application windows uniquement, et je peux déployer l'app sur tout mon parc sans devoir passer par des updates de windows pour recevoir le framework standard.
Aussi, lorsque j'ouvre un projet net core, net core se met à jour. Pratique aussi.


On est pas dans du portage et alors ? Je pense que celui qui décide de se faire une app net core + wpf assume le choix que son application ne soit pas portable.

Non, ce qui vous embête c'est que vous pensiez avoir la gui windows sur mac/linux.

Vous savez, vous avez aussi Qt.Sharp (https://github.com/ddobrev/QtSharp) qui vous permet d'avoir une gui portable.

Perso, je suis déjà fortement content de pouvoir faire de l'asp.net core sous mac/linux.

[François DORIN]

Non, ce qui vous embête c'est que vous pensiez avoir la gui windows sur mac/linux.

Pas tout à fait. Pour ma part, je m'en fiche que la GUI Windows soit dispo sur MacOS et Linux. Ce qui m'intéresse, c'est de pouvoir développer un client lourd une seule fois et qui soit portable sur chacune de ces trois plateforme. Et c'est une attente assez forte (il suffit de lire les commentaires).

Vous savez, vous avez aussi Qt.Sharp (https://github.com/ddobrev/QtSharp) qui vous permet d'avoir une gui portable.

Ce projet n'est pas vraiment actif.
La dernière fois que je l'avais testé (il y a longtemps, je le concède), j'ai eu beaucoup de mal à avoir une application fonctionnelle. De plus, elle était buggée (plantage de l'application de démo dès que je cliquais sur un menu). Enfin, comme c'est basé sur la génération automatique d'un wrapper à l'aide d'un utilitaire, j'ai des craintes sur l'interopérabilité entre les classes de base du Framework et Qt (chargement d'une icone depuis un stream par exemple).

[xarkam]

Ce projet n'est pas vraiment actif.
La dernière fois que je l'avais testé (il y a longtemps, je le concède), j'ai eu beaucoup de mal à avoir une application fonctionnelle. De plus, elle était buggée (plantage de l'application de démo dès que je cliquais sur un menu). Enfin, comme c'est basé sur la génération automatique d'un wrapper à l'aide d'un utilitaire, j'ai des craintes sur l'interopérabilité entre les classes de base du Framework et Qt (chargement d'une icone depuis un stream par exemple).

Je t'invite à tester AvaloniaUI.
C'est un projet très actif et ca répond au besoin de portabilité.

Et je dit peut-être une bêtise mais avalonstudio repose sur avalonia il me semble.

Actuellement, je n'ai pas besoin de faire un client lourd mais si d'avenir je devais en faire un, je testerais sans hésiter de framework UI.

[dfiad77pro]

Je t'invite à tester AvaloniaUI.
C'est un projet très actif et ca répond au besoin de portabilité.

Et je dit peut-être une bêtise mais avalonstudio repose sur avalonia il me semble.

Actuellement, je n'ai pas besoin de faire un client lourd mais si d'avenir je devais en faire un, je testerais sans hésiter de framework UI.

En effet c'est un beau projet,
cela dit il est actuellement très loins de WPF et les perfs sont pas top.

[xarkam]

En effet c'est un beau projet,
cela dit il est actuellement très loins de WPF et les perfs sont pas top.

Je n'ai pas fait d'app avec donc les perf, je ne peux pas en parler.

Ensuite, wpf date de quoi 2005/2006 alors que avalonia n'a que 3 ans et à démarré via du reverse engeneering. Normal qu'il soit moins fourni.