Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
XWT fonctionne avec le .NET framework 4.0+ et Mono. Je l'utilise actuellement et c'est plutôt pas mal, même si il y a encore quelques petits bugs d'affichage entre les OS. Sa fonctionne même sur Windows XP et MacOS 10.7Envoyé par François DORIN
Sinon il y a aussi Eto.Forms mais je l'ai juste testé une fois, pas vraiment utilisé...
Même si Microsoft ne fournit pas (pour le moment?) de support d'applications desktop pour le bureau Linux et Mac, j'imagine que l'accès au code source de WPF va fortement faciliter la tâche des créateurs d'Avalonia (clone libre et multiplateforme de WPF pour .NET Core).
Avalonia est déjà très prometeur et à l'instar de Mono, il n'est pas inenvisageable qu'il soit un jour officiellement intégré à .NET Core.
Avec tout ça, je pense qu'on va dans la bonne direction pour la pérennité d'un .NET libre, complet, moderne et multiplateforme.
Winforms a été porté sous Mono, donc cela doit être possible avec .NetCore. Pour WPF, il semble que le problème majeur soit sa dépendance à D3D... Le problème doit être identique pour UWP...
Après c'est pareil, en winforms mono je doute que les grosses librairies comme infragistics/KendoUi fonctionnent…
Microsoft avait fait le choix de ne pas développer de librairies de composants graphiques évolués pour que ses partenaires ne se retrouvent pas sans revenus ( et donc se détachent de Microsoft).
Même le nouveau Community Toolkit, ne propose pas encore des composants super évolués (scheduler, gantt, dataGrid avec formule etc).
bref à l'heure du tout web et des techo qui prennent une plombe à compiler (genre node+ react+webpack +scss). Je ne me fait pas d'illusion du la suite
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. Leur problème est à chaque nouveaux 'standards' on rétrograde (Win32>WPF>UWP>...). A vouloir copier Apple avec des applis, le monde pro a été oublié...
Perso je m'y perds dans tous ces framework .NET
Y'en a que deux de framework le framework .net historique qui ne va quasiment plus évolué après le 4.8. Et le framework .net core.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. Leur problème est à chaque nouveaux 'standards' on rétrograde (Win32>WPF>UWP>...). A vouloir copier Apple avec des applis, le monde pro a été oublié...
Perso je m'y perds dans tous ces framework .NET
Ensuite tu parles de choses différente win32 est un énorme problème pour windows ce n'est pas pour rien que microsoft a développé COM3 plus commu sous le nom de .net.
Surtout comparer WIN32 avec WPF j'ai du mal à comprendre le rapport... ça revient à comparer l'ABI de linux avec Php ou encore des chaussettes et des radis.
Le choses sont simple à partir de .net core 3 il faut considérer les applications GUI reposant sur wpf, uwp, winform et n'utilisant pas .net core 3 comme depredacted. A noter que leur passage sur .net core 3 se fait simplement.
A terme WPF et UWP permettront de dev des applications graphique multiplate-forme windows, osX, linux peut-être pour .net core 4 qui sait
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?
Normal le .net framework historique n'est rien d'autre que COM3 de son doux nom. Concernant le web, le problème vient surtout de la partie front mais basiquement HTML/CSS/JS sont stable le gros bordel vient des frameworks qui tournent autour.
Faut voir .net core comme étant "Common Object Model 4" mais Common pour de vrai il est sorti de son carcan windowsien.
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).
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.
?
les applis fonctionneront toujours et pour longtemps, on pourra toujours développer dessus et pour longtemps
certaines fonctionnalités ne seront pas dispo dans .net core 3 donc non tout le monde ne pourra pas migrer
on ne fait pas tous des applis avec 3 pauvres boutons et 1 appel web service
(perso l'assistant de migration .net core 3 m'a sorti des trucs qui ne seront pas dans .net core 3)
ce n'est pas parce qu'il y a une simple case à cocher dans la solution que c'est simple et que ca ne prend pas de temps
déjà il y a des tests complets de l'appli à refaire
et perso je préfère comprendre le fonctionnement de .net core avant de passer dessus, exemple avec le merge de l'exe et des dll, est-ce que la reflection ou le parcours d'assemblies loadés fonctionne toujours ?
après oui je veux bien croire que .net core soit le futur (et le présent pour certains déjà)
Win32 ça reste en 2018 le principal moyen utilisé par le reste des logiciels et autres machines virtuelles (.NET, Java...) pour communiquer avec Windows.
Cela implique des contraintes très fortes :
- Stabilité de l'API car elle doit rester compatible avec les (très) vieux logiciels, sans même une re-compilation de ceux-ci.
- Performance car si les appels au système d'exploitation sont lents, impossible de faire un logiciel performant.
- Simplicité technique pour qu'elle puisse s'interfacer facilement avec divers langages de programmation (On a eu la démo avec le VB6, le .NET, le Delphi... qui permettent tous aux développeurs de déclarer des fonctions Win32 puis de les appeler).
L'API Win32 n'est pas un problème pour Windows.
C'est un mal nécessaire avec les inconvénients qui découlent de ces contraintes.
Mais c'est une partie intégrante de Windows et ce qui lui donne la force d'avoir un catalogue de logiciels considérable.
C'est claire que le .NET ne devrait pas être un problème pour Windows vu que l'on peut le considérer comme un composant externe (quasi optionnel) supposé faciliter les développements.
Une surcouche de la librairie standard C, de l'API Win32 sous Windows et des appels systèmes Unix sur Linux et Mac.
Aujourd’hui, si vous visez juste la pérennité chez M$, je vous conseillerais simplement de vous appuyer sur l'API Win32 qui a de bonnes chances d’enterrer quelques autres frameworks et bibliothèques modernes et bien à la mode.
[message écrit via un des 3 navigateurs sur mon PC qui importent tous directement kernel32.dll, user32.dll et quelques-unes de leurs copines]
Je partage l'avis de Bart-Rennes
L'API WIN32 est la base de Windows. C'est robuste, fiable, performant et relativement simple.
Tout les reste (.net et consorts) n'apporte que des complications et ne fait pas avancer le schmilblick (on réinvente la roue, pas forcément en mieux). Perso j'ai décroché...
Perso, là où j'ai décroché, c'est avec .NET s'oriente à 100% vers WPF et consors.
J'ai toujours pas compris ce que ça apportait par rapport à WinForms.
Si WinForms est un warp des API Win32, soit.
Je ne vois pas pourquoi il faudrait changer la logique de programmation pour pouvoir rendre le Framework portable.
C'est justement le rôle d'un warper.
Aujourd'hui, il est extrêmement compliqué de passer de l'un à l'autre : il faut tout réécrire la couche GUI.
A l'époque de Windows Mobile <= 7, converture du code Win32 et WinMobile se faisait en quelques minutes.
Là, Microsoft s'entête dans une voie de merde qui veut singer le web, qui à l'origine singe lui-même le Win32.
Ca a sonné la mort de Windows 10 Mobile avec son UWP que personne n'a même cherché à comprendre : c'est une merde sans nom, avec 25 fichiers de code imbitables pour afficher un pauvre Hello World qui ressemble à rien.
Que Microsoft porte correctement Win32 comme il a su le faire avec SQL Server, et d'un coup .NET s'imposera largement sur Linux. Mais tant qu'ils resteront dans cette voie de pseudo code XML interprété pour faire la couche graphique, personne ne fera l'effort de migrer massivement des applications vers .NET Core.
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
1/ Je ne parle pas de généralité me de "perso", "dans mon cas", "j'ai"
2/ Je ne parle pas de savoir si "c'est mieux ou moins bien", mais avant tout de l'utilité de faire différemment (et j'insiste, bien plus complexe, aussi bien pour le développeur que pour le compilateur et le framework, et plus lourd) des choses qu'on sait déjà parfaitement faire
3/ Et surtout du portage du code : l'intérpet de .NET Core, c'est de pouvoir faire tourner nos applications Windows écrites en .NET sur toutes les plateformes... Sauf qu'il faut commencer par les réécrire !
Je rappelle quand même l'échec cuisant de Windows 10 Mobile et de la mort annoncée de UWP... C'est pas moi qui le dit, c'est Microsoft qui s'est planté.
C'est pas parce que WPF est mieux (ou même pire) que Microsoft c'est planté. Mais simplement parceque ça ne supporte plus du tout le code écrit pour Win32.
Et on parle pas de VB6 ni de Windows 3.1 hein. La moindre application écrite en WinForms .NET, faut jeter 50% du code, voir plus, pour pouvoir la porter sur .NET Core. C'est juste une aberration !
D'autant plus que Mono permet de faire tourner du code WinForms sur toutes les plateformes supportées.
Il n'y a aucune raison pour que Microsoft sache dessiner un bouton sous Linux avec WPF et pas avec un warper Win32 : derrière, que ça génère un code intermédiaire XAML, je m'en tamponne le bourrichon, tant que j'ai pas à réécrire mon interface en XAML...
tu n'as pas compris la news alors
.net core est fait pour être portable
.net core n'a pas de brique graphique
.net core 3 permettra de faire des exe winforms et wpf mais qui ne tourneront que sous windows.
donc :
- winforms aussi si tu ne veux pas de wpf
- pas multiplateforme tout comme avec .net framework 4.x
-.net core n'aura toujours pas de brique graphique
et la plupart du code est compatible donc pas forcément de code à réécrire, c'est juste si tu utilisais des trucs qui ne sont pas dans .net core
certains pourront basculer une appli winforms de 4.x vers core 3 sans rien réécrire
donc je ne comprends pas ton histoire que ms veut te forcer à faire du xaml et que tu vas réécrire 50% du code ...
quant à l'utilité de tout faire différemment en wpf qu'en Windows forms il y en a une même si tu ne l'as pas compris, tout comme il y a eut une un jour une utilité à inventer le C++ après le C
La mort de Windows 10 Mobile n'a rien à voir avec cela. La mort de Windows 10 mobile est surtout dû à l'arriver tardif de Microsoft sur le marché. Avec une part de marché de quelques pourcents seulement face aux mastodontes iOS/Android, ils n'ont rien pu faire, et se sont retrouver dans le schéma classique où le serpent se mord la queue : il n'y a pas d'application sur Windows 10 mobile car il n'y a qu'une faible part du marché, et il n'y a qu'une faible part de marché car la plupart des applications n'existent pas sous Windows 10 Mobile. End of Story.
Tu ne vois pas d'avantages à .NET par rapport à du code Win32 classique. C'est dommage. Je peux te citer :
- sécurisation (langage à VM, fini les libérations de mémoire et les buffers overflow) ;
- beaucoup moins de ligne de code (super pour la maintenance et la rapidité d'écriture des logiciels) ;
- interopérabilité entre les différents langages supportant .NET de manière totalement transparente ;
- indépendant de l'architecture cible (x86, x64, ou même ARM maintenant), sauf cas très particulier.
Au sujet du XAML, un des objectifs de séparation de l'UI et du code était de permettre de séparer les tâches de développement des tâches de conception graphique. Le designer n'a alors plus besoin d'être développeur (chose nécessaire avec WinForm, même si le designer de Visual Studio aide pas mal, j'ai toujours été obligé de passer par du code à un moment ou à un autre dans une application un tant soit peu complexe).
Enfin, .NET Core ne signifie pas la mort de .NET classique. Il faut arrêter de cataloguer des produits/techno comme obsolète car de nouvelles sortent. J'entends depuis des lustres que Win32 est obsolète. Foutaise !!!! Nombre d'actions spécifiques ne peuvent se faire que via l'API Win32 ! Le fait que Microsoft ait choisi de privilégier .NET Core pour le côté portabilité ne signifie pas la mort du Framework .NET. Il a atteint une certaine maturité aujourd'hui, et les ajours niveau API sont largement couvert pour la quasi totalité des besoins.
Relisez un peu plutôt que de me lyncher sur place.
Je n'ai jamais dit que .NET était pourri ou autre, et pour cause, je ne code qu'en C#.
On parle du namespace System.Windows, basé en grande partie sur Win32, et qui n'est pas porté sur .NET Core pour cette unique raison.
Pour moi c'est une connerie, tout comme le fait qu'il n'est pas présent dans les applications UWP.
Ça oblige à refaire totalement différemment tout le code de la GUI, et c'est la principale raison pour laquelle personne ne mon entourage n'a sauté le pas.
Pourquoi se faire chier à écrire spécifiquement du code UWP pour n'avoir comme seul avantage que c'est compatible avec Windows 10 Mobile ?
C'est rigoureusement ce qui attends .NET Core sur Linux : pourquoi s'emmerder à coder une GUI spécifique pour s'ouvrir à une faible minorité d'utilisateurs Linux ? (je parle bien d'utilisateurs, pas de serveurs).
Quand on a un logiciel qui contient des centaines de composants Windows.Form, c'est juste rédhibitoire de devoir tout convertir en WCF.
Et accessoirement, les performances ne sont pas au rendez-vous avec WCF : plus lourd en mémoire et plus lent à l'exécution.
Le seul (principal) avantage, c'est que c'est vectoriel et s'adapte donc à toutes les tailles d'écran... Et encore, j'aimerais bien voir une application qui utilise la même fenêtre pour un écran de 24" et pour un téléphone de 4".
Le côté "reactive", ça n'a rien à voir avec WCF. Ceux qui croient qu'on peut pas faire de reactive avec Win32 sont de sombres crétins qui ne savent pas coder... Le multi-threading ca date quand même pas de C# 4 hein.
Ce n'est pas du lynchage. Perso, en te lisant, cela ne transparait pas que tu fais du .NET (et pourtant je le sais, tu interviens régulièrement sur les forums
Je pense aussi que UWP, c'est de la merde. D'une part car il faut réécrire le code, mais aussi à cause de nombreuses limitations qui font que nombres d'applications ne peuvent pas être UWP, et du pourrissage de l'expérience utilisateur (vouloir une seule application "universelle" alors que les périphériques sont différents est juste un non sens. On ne manipule pas une application de la même manière en fonction de la taille de l'écran, de la présence d'un clavier, d'une souris, ou d'un écran tactile).
Tu veux sans doute parler de WPF. Maintenant, je suis d'accord avec toi. C'est juste super chiant de devoir tout réécrire. Rédhibitoire même. Perso, je rêve qu'un framework GUI soit enfin intégré à .NET Core. Mais ce n'est pas prévu. Je pense que Microsoft le fait volontairement pour laisser le champ libre aux Framework tiers. Du coup, pour l'instant, on ne voit que des systèmes basées sur des techno type Electron, où il faut faire du HTML/CSS/JS.
Il y a quelques framework qui commencent à apparaître, mais il est encore trop tôt pour une utilisation en production (je ne peux pas me permettre d'utiliser cela avec mes clients).
Répondre avec citation
Partager