+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Responsable .NET

    Avatar de Hinault Romaric
    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2007
    Messages
    4 532
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 4 532
    Points : 251 254
    Points
    251 254
    Billets dans le blog
    84

    Par défaut .NET Core 3.0 offrira un support du développement d’applications de bureau

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

    Nom : dotnet-core3.png
Affichages : 2064
Taille : 52,5 Ko

    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
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

  2. #2
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2008
    Messages
    441
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : FrancesƆ

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 441
    Points : 1 319
    Points
    1 319

    Par défaut

    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

  3. #3
    Responsable DotNet & Magazine

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 039
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 039
    Points : 7 367
    Points
    7 367
    Billets dans le blog
    14

    Par défaut

    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.
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  4. #4
    Membre averti
    Inscrit en
    juin 2010
    Messages
    401
    Détails du profil
    Informations forums :
    Inscription : juin 2010
    Messages : 401
    Points : 427
    Points
    427

    Par défaut

    Citation Envoyé par François DORIN Voir le message
    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

  5. #5
    Responsable DotNet & Magazine

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 039
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 039
    Points : 7 367
    Points
    7 367
    Billets dans le blog
    14

    Par défaut

    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.
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  6. #6
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    avril 2007
    Messages
    13 085
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : avril 2007
    Messages : 13 085
    Points : 23 821
    Points
    23 821

    Par défaut

    un peu déçu aussi, j'aurais préféré un "nouveau" framework UI utilisant xaml et portable ...
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  7. #7
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2008
    Messages
    441
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : FrancesƆ

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 441
    Points : 1 319
    Points
    1 319

    Par défaut

    Citation Envoyé par François DORIN Voir le message
    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)

  8. #8
    Responsable DotNet & Magazine

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 039
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 039
    Points : 7 367
    Points
    7 367
    Billets dans le blog
    14

    Par défaut

    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
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  9. #9
    Membre confirmé
    Profil pro
    Développeur .NET
    Inscrit en
    février 2005
    Messages
    224
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2005
    Messages : 224
    Points : 503
    Points
    503

    Par défaut

    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.

  10. #10
    Membre à l'essai
    Profil pro
    Inscrit en
    juin 2008
    Messages
    17
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2008
    Messages : 17
    Points : 23
    Points
    23

    Par défaut

    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.

  11. #11
    Expert confirmé
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    3 193
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 3 193
    Points : 5 180
    Points
    5 180
    Billets dans le blog
    1

    Par défaut

    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...
    On ne jouit bien que de ce qu’on partage.

  12. #12
    Membre averti
    Inscrit en
    juin 2010
    Messages
    401
    Détails du profil
    Informations forums :
    Inscription : juin 2010
    Messages : 401
    Points : 427
    Points
    427

    Par défaut

    Citation Envoyé par StringBuilder Voir le message
    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.

  13. #13
    Responsable DotNet & Magazine

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 039
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 039
    Points : 7 367
    Points
    7 367
    Billets dans le blog
    14

    Par défaut

    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...
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  14. #14
    Expert confirmé
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    3 193
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 3 193
    Points : 5 180
    Points
    5 180
    Billets dans le blog
    1

    Par défaut

    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.
    On ne jouit bien que de ce qu’on partage.

  15. #15
    Responsable DotNet & Magazine

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 039
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 039
    Points : 7 367
    Points
    7 367
    Billets dans le blog
    14

    Par défaut

    Citation Envoyé par StringBuilder Voir le message
    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é".
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  16. #16
    Membre confirmé
    Profil pro
    Développeur .NET
    Inscrit en
    février 2005
    Messages
    224
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2005
    Messages : 224
    Points : 503
    Points
    503

    Par défaut

    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.

  17. #17
    Responsable DotNet & Magazine

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 039
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 039
    Points : 7 367
    Points
    7 367
    Billets dans le blog
    14

    Par défaut

    Citation Envoyé par xarkam Voir le message
    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).

    Citation Envoyé par xarkam Voir le message
    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).
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  18. #18
    Membre confirmé
    Profil pro
    Développeur .NET
    Inscrit en
    février 2005
    Messages
    224
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2005
    Messages : 224
    Points : 503
    Points
    503

    Par défaut

    Citation Envoyé par François DORIN Voir le message
    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.

  19. #19
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2008
    Messages
    441
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : FrancesƆ

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 441
    Points : 1 319
    Points
    1 319

    Par défaut

    Citation Envoyé par xarkam Voir le message
    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.

  20. #20
    Membre confirmé
    Profil pro
    Développeur .NET
    Inscrit en
    février 2005
    Messages
    224
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2005
    Messages : 224
    Points : 503
    Points
    503

    Par défaut

    Citation Envoyé par dfiad77pro Voir le message
    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.

Discussions similaires

  1. Réponses: 0
    Dernier message: 23/08/2017, 02h14
  2. Réponses: 1
    Dernier message: 12/05/2017, 17h04
  3. Réponses: 1
    Dernier message: 05/09/2016, 01h52
  4. Réponses: 1
    Dernier message: 10/05/2016, 09h28
  5. Réponses: 9
    Dernier message: 24/03/2011, 15h33

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo