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 Core 3.0 offrira un support du développement d'applications de bureau
Mais sur Windows uniquement

Le , par Hinault Romaric

168PARTAGES

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

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

Avatar de François DORIN
Expert éminent sénior https://www.developpez.com
Le 08/05/2018 à 15:48
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.
5  0 
Avatar de François DORIN
Expert éminent sénior https://www.developpez.com
Le 09/05/2018 à 14:04
Citation Envoyé par redcurve Voir le message
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.

Citation Envoyé par redcurve Voir le message
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...
4  0 
Avatar de François DORIN
Expert éminent sénior https://www.developpez.com
Le 08/05/2018 à 17:57
Citation Envoyé par redcurve Voir le message
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 ?

Citation Envoyé par redcurve Voir le message
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.
4  1 
Avatar de Pol63
Expert éminent sénior https://www.developpez.com
Le 08/05/2018 à 18:05
un peu déçu aussi, j'aurais préféré un "nouveau" framework UI utilisant xaml et portable ...
3  0 
Avatar de François DORIN
Expert éminent sénior https://www.developpez.com
Le 08/05/2018 à 19:03
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
3  0 
Avatar de François DORIN
Expert éminent sénior https://www.developpez.com
Le 10/05/2018 à 11:44
Citation Envoyé par Kikuts Voir le message
Pour ceux qui ne savent pas, avec Xamarin Forms, on peut déployer sur iOS, Android, Windows (desktop, Xbox et euh comment il s'appel ? Ah oui windows phone), MacOs, Linux, même les smartwatch Apple & co ainsi que les TV...
La seule plateforme manquante est le web.
Ou peut-etre justement qu'on connait Xamarin Forms.
Je corrige ta phrase : Pour ceux qui ne savent pas, avec Xamarin Forms, on peut déployer sur iOS, Android, Windows UWP(desktop, Xbox et euh comment il s'appel ? Ah oui windows phone), MacOs, Linux, même les smartwatch Apple & co ainsi que les TV...

Le support pour Windows (non UWP), Linux et MacOS ne sont que des previews (et même des pré-preview pour Linux et Windows). Donc inutilisable pour un projet à l'heure actuelle. Et UWP souffre de nombreuses limitations par rapport à une application de bureau classique, ce qui ne convient donc pas pour un grand nombre de cas.

Aujourd'hui, il n'y a pas de solutions stables pour faire des applications de bureau compatibles Windows, Linux et MacOS. Les solutions sont en cours de développement, plus maintenu, ou en béta dans le meilleur des cas. Sinon, il faut se tourner vers des solutions style Electron (mais qui nécessite donc des connaissances en HTML, JS et CSS).
3  0 
Avatar de François DORIN
Expert éminent sénior https://www.developpez.com
Le 10/08/2018 à 11:02
Citation Envoyé par frfancha Voir le message
QT.
Non. Remet dans le contexte : pas en .NET .

Citation Envoyé par hotcryx
https://en.wikipedia.org/wiki/List_of_widget_toolkits
En C# est cité :
  • GTK#. Binding de GTK, dont le portage Windows est douloureux (bugs, comportement différents, etc...). Bref, pas vraiment utilisable pour faire un code véritablement portable ;
  • Winform. Marche très bien sous Windows (normal), moins bien sous Linux et MacOS car l'implémentation faite par Mono n'est malheureusement pas fidèle 100% (malgré une très bonne fidélité en général).


Bref, aujourd'hui, à moins de se tourner vers une solution comme Electron, il n'existe pas de framework ou de binding en .NET permettant de faire des applications graphiques de manière portable. Les différents projets existant sont abandonné, dans un état de proof of concept, en cours de développement ou bogué.

Donc je réitère : pas de toolkit graphique stable et utilisable pour faire des applications graphiques en .NET, à moins d'utiliser une solution type Electron.
3  0 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 21/12/2018 à 9:30
Citation Envoyé par Wikipedia
Win32, successeur de Win16, a été introduit en 1993,
C'est quand meme normal d'avoir d'autres produits sortis depuis, et tu noteras qu'il est toujours possible 25 ans plus tard d'utiliser/mélanger du .Net avec du win32... On reparle des technos web d'aujourd'hui qui n'existeront plus dans 5 ans?
2  0 
Avatar de François DORIN
Expert éminent sénior https://www.developpez.com
Le 21/12/2018 à 15:28
Citation Envoyé par redcurve Voir le message
Normal le .net framework historique n'est rien d'autre que COM3 de son doux nom.
Je veux bien des info là dessus, car je n'ai jamais, et je dis bien jamais, entendu parlé de .NET comme étant COM3 (et j'ai beau faire des recherches, je ne trouve rien sur le sujet).

Citation Envoyé par bartrennes
J'en pense que c'est bien d'essayer de nouvelles choses et d'évoluer mais que je ne fais plus confiance sur les projets de Microsoft, on lance un projet avec le minimum de fonction puis on attends et on arrête dans la majeur partie des cas.
On peut reprocher des choses à Microsoft, mais du point de vue pérennité, je pense qu'ils sont plutôt bien placés. Les programmes développés pour Windows 98 fonctionnent encore aujourd'hui, notamment grâce à une très bonne stabilité des APIs.

Ensuite, les techno évoluent, obligeant parfois à prendre des décisions radicales. Ce fut le cas pour Silverlight par exemple, où c'est l’émergence de HTML5/CSS/JS qui a rendu cette techno complètement inutile. De plus, et comme déjà évoqué, comparer Win32 et WPF/UWP est un non sens.

Il faut également arrêter de voir un arrêt d'évolution d'une technologie comme un signe indiquant qu'elle est dépréciée : quand une techno est mature, pourquoi continuer sans cesse de la faire évoluer, avec les risques que cela induit quand la pérennité est un élément clé ?

.NET core 3 c'est très bien, mais a des limites, notamment si on souhaite faire un programme graphique portable, ou du point de vue de la pérennité (les professionnels aiment ça, car ils n'ont pas envie de redévelopper ou mettre à jour une application qui fonctionnent très bien juste parce qu'une brique a été mise à jour, avec les risques que cela induit). Passer de .NET Core 2 à 3 nécessite de retester entièrement ses applications pour s'assurer qu'il n'y a pas de changements subtils.
2  0 
Avatar de Pol63
Expert éminent sénior https://www.developpez.com
Le 29/12/2018 à 12:16
faut arrêter de prendre vos cas pour des généralités
ce n'est pas parce que vous ne comprenez pas .net, wpf ou uwp (ou leur interet) que c'est le cas de tout le monde

.net par rapport à vb6 ca fait diminuer d'entre 5 et 20 fois le nombre de lignes de code grace à la POO, linq et autres, ca permet donc de coder plus vite, et aussi d'avoir du code plus maintenable et quand on est sur un gros projet c'est juste vital
wpf (et uwp par extension) ca permet encore de baisser le nombre de lignes de code, ca permet de faire plus vite son interface, ca permet de faire une interface plus dynamique plus facilement, ca permet de bien séparer ui et code
99% de ce qu'on peut faire visuellement en wpf est faisable en winforms certes, mais à quel prix ...

alors oui wpf c'est différent à utiliser de winforms, mais la POO c'est aussi différent du code procédural d'il y a 25 ans
il faut prendre le temps d'essayer, de comprendre la philosophie, pour voir si ca correspond à notre besoin et si on apprécie le langage
pour passer d'un langage à un autre il faut souvent désapprendre des façons de faire, mais pour un nouveau qui se lance sur du XAML peut etre que ca sera aussi intuitif pour lui que controls.add l'était pour nous en winforms à nos débuts
2  0