Microsoft rappelle que .NET Core 3.0 va arriver en fin de vie le 3 mars 2020

Version imprimable

Voir 40 message(s) de cette discussion en une page

08/05/2018, 12h30
Hinault Romaric

1 pièce(s) jointe(s)

Microsoft rappelle que .NET Core 3.0 va arriver en fin de vie le 3 mars 2020
.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.

Pièce jointe 378175

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 ?

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

Voir aussi :

:fleche: Microsoft annonce la disponibilité de Visual Studio 2017 version 15.7 : un tour d'horizon des nouveautés de l'EDI
:fleche: Microsoft annonce la disponibilité de .NET Core 2.1 RC1, cette version peut déjà être utilisée en production
:fleche: Build 2018 : Microsoft annonce la disponibilité en préversion publique de VS Live Share, son extension de développement collaboratif en temps réel
08/05/2018, 15h43
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 8-)
08/05/2018, 15h48
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.
08/05/2018, 17h44
redcurve

Citation:

Envoyé par 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.

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
08/05/2018, 17h57
François DORIN

Citation:

Envoyé par redcurve

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

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.
08/05/2018, 18h05
Pol63

un peu déçu aussi, j'aurais préféré un "nouveau" framework UI utilisant xaml et portable ...
08/05/2018, 18h49
dfiad77pro

Citation:

Envoyé par François DORIN

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)
08/05/2018, 19h03
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
08/05/2018, 19h10
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.
08/05/2018, 23h01
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.
09/05/2018, 08h57
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...
09/05/2018, 13h27
redcurve

Citation:

Envoyé par 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...

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.
09/05/2018, 14h04
François DORIN
Citation:

Envoyé par redcurve

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

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...
09/05/2018, 14h11
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.
09/05/2018, 14h24
François DORIN
Citation:

Envoyé par 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 ?

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é".
09/05/2018, 15h02
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.
09/05/2018, 15h30
François DORIN

Citation:

Envoyé par xarkam

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

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).
09/05/2018, 17h01
xarkam

Citation:

Envoyé par François DORIN

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.
09/05/2018, 17h59
dfiad77pro

Citation:

Envoyé par xarkam

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.
09/05/2018, 22h23
xarkam

Citation:

Envoyé par dfiad77pro

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.
10/05/2018, 11h19
Kikuts

Je ne comprends pas ce qui vous pose problème ?

Cette initiative est juste géniale ! Pouvoir faire évoluer un vieux projet winforms en intégrant un user control écrit en Xaml ? C'est juste trop cool !

J'ai lu plusieurs fois que certains auraient préféré un nouveau framework pour pouvoir cibler n'importe quelle plateforme. Euh... Vous avez essayez Xamarin Forms ? Parce que si c'est pour refaire Xamarin Forms et le renommer en XamlEverywhere ou un truc comme ça, aucun intérêt.

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.

Même pour faire du spécifique Windows UWP, s'il n'y a ps besoin de truc super avancée en cartographie, je pars sur Xamarin cache (euh cash :mouarf:).
J'ai fais plusieurs app en XForms que j'ai réussi à déployer partout, les perf sont top pour une techno multiplateforme.

Donc je ne vois pas l'intérêt de réinventer la roue (qu'ils possèdent eux même d'ailleurs), au contraire, ça rendrait les technos flous et on finirait par partir sur Electron....
10/05/2018, 11h44
François DORIN

Citation:

Envoyé par Kikuts

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).
09/08/2018, 15h07
Michael Guilloux

Vos applications Windows Forms et WPF sont-elles prêtes pour .NET Core 3.0 ?
Vos applications Windows Forms et WPF sont-elles prêtes pour .NET Core 3.0 ?
Microsoft veut s'en assurer et sollicite les développeurs

Lors de la dernière édition de sa conférence Build en mai, Microsoft a fait une annonce qui a surpris plus d'un développeur : .NET Core 3.0 va prendre en charge le développement d'applications de bureau, mais cette nouveauté sera uniquement disponible pour Windows. Ainsi, avec .NET Core 3.0, les développeurs seront en mesure d'exécuter de nouvelles applications de bureau Windows ou des applications de bureau existantes sur .NET Core et profiter de tous les avantages de la plateforme. Lesquels avantages sont entre autres :
- 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.
.NET Core a pourtant été présenté comme une version multiplateforme de .NET Framework. Microsoft a donc abandonné les technologies de Framework .NET liées à Windows afin que .NET Core soit ouvert à d'autres plateformes, notamment Linux et macOS. .NET Core n'offre donc pas de prise en charge de ASP.NET WebForms, Windows Forms et Windows Presentation Foundation (WPF). Ce qui ne fait pas l'affaire de nombreux développeurs, qui n'ont pas manqué d'exprimer leur besoin auprès de Microsoft. L'annonce du support des applications Windows desktop, plus précisément de Windows Forms et Windows Presentation Framework (WPF), est donc une réponse à la demande de ces derniers. Ce support sera ajouté sous la forme d'un ensemble de packages sous le nom de « Windows Desktop Packs ».

Maintenant que Microsoft a fait cette annonce, il faut s'assurer de la qualité de ce support, notamment en ce qui concerne le portage des applications existantes. Pour cela, le géant du logiciel met à la disposition des développeurs l'outil Portability Analyzer, pour leur permettre de savoir si leurs applications Windows Forms et WPF sont prêtes à être portées sur .NET Core 3.0.

« Nous voulons nous assurer que .NET Core 3.0 inclut toutes les API dont dépendent vos applications Windows Forms et WPF. Ainsi, afin de savoir quelles API sont utilisées, nous publions Portability Analyzer qui signalera l'ensemble des API référencées dans vos applications qui ne sont pas encore disponibles dans NET Core 3.0. Cette liste d'API sera envoyée à Microsoft et nous aidera à définir les API à intégrer [à .NET Core 3.0] avant sa livraison », explique l'équipe .NET dans un billet de blog.

L'analyseur de portabilité, qui est un outil open source, vise donc à simplifier votre expérience de portage, et pour cela, Microsoft invite les développeurs à le télécharger et l'exécuter sur leurs applications. « Afin que nous puissions connaître les API dont nos utilisateurs ont besoin, nous vous demandons d’exécuter l’outil qui nous aidera à fournir la meilleure expérience possible dans le portage de vos applications. En même temps, vous verrez à quel point vos applications sont portables, car l'outil génère une liste d'API référencées dans vos assemblys, qui pourraient ne pas être prises en charge dans .NET Core 3.0. »

https://www.developpez.com/public/im...RE3DESKTOP.png
Présentation de l’outil Portability Analyzer

L'exécution de l'outil fera deux choses. Elle va générer une feuille Excel qui signalera le niveau de compatibilité de votre projet avec .NET Core 3.0, en précisant les API spécifiques de votre projet qui ne sont pas actuellement prises en charge. Mais elle va également envoyer ces mêmes données à l'équipe .NET de Microsoft, pour qui cela servira à déterminer quelles API sont nécessaires pour le plus grand nombre. À part ces informations, aucune autre (ni code source ni binaires) ne sera envoyée de votre ordinateur à Microsoft. L'équipe .NET insiste également sur le fait que l'ajout de nouvelles API à .NET Core 3.0 se fera en fonction des informations collectées. Les développeurs sont donc invités à télécharger et exécuter l'outil, pour s'assurer que leurs applications et leurs API spécifiques seront prises en compte.

:fleche: Télécharger l'outil Portability Analyzer sur GitHub

Et vous ?

:fleche: Depuis l'annonce de Microsoft en mai, avez-vous étudié les avantages et inconvénients du support des applications Windows desktop sur .NET Core 3.0 ?
:fleche: Si oui, pouvez-vous les partager et les expliquer ?
:fleche: Comptez-vous déjà développer de nouvelles applications Windows Forms ou WPF avec .NET Core 3.0 ou porter des applications existantes ? Dans quels buts ?

Voir aussi :

:fleche: .NET Framework 4.7.2 est disponible, avec le support de l'injection de dépendance dans les Web Forms et la sécurisation de cookies avec SameSite
:fleche: La préversion de la compilation hiérarchisée est disponible dans .NET Core 2.1, pour tirer le meilleur parti du démarrage et de l'exécution d'une app
:fleche: Microsoft annonce la sortie de .NET Core 2.1, avec de nombreux ajouts et améliorations qui viennent enrichir cet environnement
:fleche: .NET Core 3.0 offrira un support du développement d'applications de bureau, mais sur Windows uniquement
:fleche: Microsoft annonce la disponibilité de .NET Core 2.1 RC1, cette version peut déjà être utilisée en production

Source : Blog .NET
10/08/2018, 07h45
frfancha

Citation:

Envoyé par François DORIN

Aujourd'hui, il n'y a pas de solutions stables pour faire des applications de bureau compatibles Windows, Linux et MacOS

QT.
10/08/2018, 10h47
hotcryx

https://en.wikipedia.org/wiki/List_of_widget_toolkits

:o
10/08/2018, 11h02
François DORIN
Citation:

Envoyé par frfancha

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.
10/08/2018, 11h10
frfancha

Citation:

Envoyé par François DORIN

Non. Remet dans le contexte : pas en .NET .
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.

Le lien entre Electron et .NET ??
10/08/2018, 11h16
François DORIN

Le lien ? C'est une solution utilisable en .NET.
10/08/2018, 12h21
frfancha

Citation:

Envoyé par François DORIN

Le lien ? C'est une solution utilisable en .NET.

Déso, je ne comprends pas comment Electron est plus lié à .NET que QT.
Quelque chose m'échappe.
Peux-tu préciser?
10/08/2018, 12h31
François DORIN

A la base, Electron et Qt sont deux techno qui n'ont rien à voir avec .NET. Qt, c'est du C++ et Electron, c'est du NodeJS/Chromium/HTML/CSS/JS

Maintenant, il est possible d'utiliser Electron dans un programme .NET car il y a eu un binding de développé pour cela.

Ce n'est pas le cas pour Qt. Il y a bien eu des projets de bindings, mais ils ne sont plus maintenu / pas abouti. Autrement dit, rien d'utilisable aujourd'hui.
10/08/2018, 18h57
redcurve

Citation:

Envoyé par François DORIN

A la base, Electron et Qt sont deux techno qui n'ont rien à voir avec .NET. Qt, c'est du C++ et Electron, c'est du NodeJS/Chromium/HTML/CSS/JS

Maintenant, il est possible d'utiliser Electron dans un programme .NET car il y a eu un binding de développé pour cela.

Ce n'est pas le cas pour Qt. Il y a bien eu des projets de bindings, mais ils ne sont plus maintenu / pas abouti. Autrement dit, rien d'utilisable aujourd'hui.

J'espère que MS pourra nous sortir un framework Xaml qui marche partout, enfin Xaml plutôt un moteur de rendu en fait Xaml n'étant qu'une "sérialisation" d'interface
11/08/2018, 23h17
MABROUKI

bonjour
le package cité « Windows Desktop Packs ».est-il disponible en téléchargement ?

Car je veux utiliser l'assembly "System.Numerics" qui dispose des primitives mathématiques 3D en Winforms Classiques et permet un calcul "hardware accelerated" même en x86...
13/08/2018, 17h10
VinceB85

Citation:

Envoyé par François DORIN

pas de toolkit graphique stable et utilisable pour faire des applications graphiques en .NET

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.7 8O
Sinon il y a aussi Eto.Forms mais je l'ai juste testé une fois, pas vraiment utilisé...
05/10/2018, 19h27
Coriolan

1 pièce(s) jointe(s)

Microsoft revient avec plus de détails sur .NET Core 3.0 et .NET Framework 4.8

Microsoft revient avec plus de détails sur .NET Core 3.0 et .NET Framework 4.8
bientôt une dissemblance entre le Framework .NET et .NET Core

En mai, nous vous annoncions que .NET Core 3.0 va offrir un support du développement d'applications de bureau. Pour rappel, .NET Core a été développé avec pour objectif principal 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.

Pièce jointe 417634

.NET Core n’offrait pas de prise en charge de ASP.NET WebForms, Windows Forms et Windows Presentation Foundation (WPF). Cela veut dire que .NET Core a été disponible sans prise en charge d’un Framework d’interface utilisateur au grand désarroi de nombreux développeurs. Néanmoins, Microsoft a promis d’adresser cette question en rendant la prise en charge du développement d’applications Desktop Windows dans .NET Core 3.0 sa principale priorité.

Dans un billet de blog, Microsoft est revenue avec plus de détails sur le futur de .NET Core et .NET Framework.

.NET Core 3.0 va adresser trois scénarios que la communauté des développeurs ont demandés auprès de Microsoft :

Des versions côte à côte de .NET qui supportent Winforms et WPF : Microsoft explique qu’aujourd’hui, il ne peut y avoir qu’une seule version de .NET Framework sur une machine. Ce qui veut dire qu’avec l’installation d’une mise à jour de .NET Framework via Patch Tuesday ou par des mises à jour de Windows, il y a un risque qu’un correctif de sécurité, un correctif de bogue ou une nouvelle API puisse casser le fonctionnement d’applications sur la machine. Avec .NET Core, Microsoft entend résoudre ce problème en permettant la coexistence de multiples versions de .NET Core sur la même machine. Les applications peuvent dès lors être verrouillées à une version spécifique et passées à une autre version après qu’elles sont testées et prêtes.

Intégrer .NET directement dans une application : Aujourd’hui, puisqu’une seule version de .NET Framework peut être installée sur une machine, il est impératif d’installer la dernière version pour tirer avantage d’une nouvelle fonctionnalité du framework ou du langage. Avec .NET Core, vous pouvez livrer le framework avec votre application. Cela permet de tirer parti de la dernière version, fonctionnalités et API sans avoir à attendre l’installation du framework.

Bénéficier des fonctionnalités de .NET Core : .NET Core constitue une version évolutive et open source de .NET. Désormais les applications WinForms et WPF sur Windows peuvent tirer profit des dernières fonctionnalités de .NET Core, qui incluent aussi plus de correctifs essentiels pour un support meilleur d’écrans à haute résolution.

Les nouveautés de .NET Framework 4.8

Des contrôles modernes du navigateur et média : Aujourd’hui, les applications desktop .NET utilisent Internet Explorer et Windows Media Player pour afficher des fichiers HTML et média. Puisque ces contrôles anciens ne supportent pas les derniers fichiers HTML et média, Microsoft est en train d’ajouter de nouveaux contrôles qui tirent parti de Microsoft Edge et de nouveaux lecteurs média qui supportent les derniers standards.

Accès aux contrôles du tactile et UWP : UWP (Universal Windows Platform) contient de nouveaux contrôles qui tirent parti des dernières fonctionnalités de Windows et des écrans tactiles. Les développeurs n’auront pas à réécrire leurs applications pour utiliser ces nouvelles fonctionnalités et contrôles. Microsoft entend les rendre disponibles pour WinForms et WPF pour qu’ils puissent en profiter dans leur code existant.

Les améliorations pour les écrans à haute résolution : La résolution des écrans ne cesse d’augmenter passant à une résolution 4K et même 8K. Ces améliorations visent à s’assurer que les applications WinForms et WPF existantes s’affichent bien sur ces écrans.

Feuille de route de .NET Framework et .NET Core

.NET Framework constitue l’implémentation de .NET installée sur plus d’un milliard de machines. Elle doit assurer la meilleure compatibilité possible. En conséquence, son développement avant à pas lents comparé à .NET Core qui est lui une version open source, multiplateforme et évolutive de .NET. En raison de sa nature, il peut recevoir des changements que Microsoft ne peut tout simplement pas prendre le risque d’implémenter dans .NET Framework. Cela veut dire qu’il faut s’attendre à une dissemblance entre .NET Framework et .NET Core puisque ce dernier va continuer à recevoir de nouvelles API et fonctionnalités du langage qui ne peuvent pas être implémentées dans le premier.

« Nous allons continuer à faciliter la migration d’applications vers .NET Core. .NET Core 3.0 fait un énorme pas en avant en ajoutant le support de WPF, WinForms et Entity Framework 6, et nous allons continuer à porter des API et fonctionnalités pour aider à combler l’écart et faciliter la migration pour ceux qui choisissent de le faire, » a écrit Scott Hunter de Microsoft.

« Si vous avez des applications .NET Framework, vous n’êtes pas pressés de passer à .NET Core. .NET Framework et .NET Core vont aller en avant, et les deux seront complètement supportés. .NET Framework fera toujours partie de Windows. Mais en avançant, ils vont avoir des fonctionnalités différentes. Même au sein de Microsoft, nous avons de larges produits basés sur .NET Framework et qui vont rester sur .NET Framework. ».

Source : blog Microsoft

Et vous ?

:fleche: Qu’en pensez-vous ?
:fleche: Comptez-vous déjà développer de nouvelles applications Windows Forms ou WPF avec .NET Core 3.0 ou porter des applications existantes ? Dans quels buts ?

Voir aussi

:fleche: Bing.com tourne désormais sur .NET Core 2.1, un choix technique qui lui a permis de gagner en performance, mais aussi en agilité
:fleche: Microsoft annonce la diffusion de mises à jour cumulatives pour .NET Framework à compter de la mise à jour Windows 10 octobre 2018
:fleche: PowerShell Core 6.1 est disponible : support de .NET Core 2.1, compatibilité avec les modules Windows, cmdlets et rendu Markdown et plus
04/11/2018, 08h29
Christian Olivier

1 pièce(s) jointe(s)

Microsoft annonce que ASP.NET Core 3.0 fonctionnera uniquement sur .NET Core 3.0

Microsoft annonce que ASP.NET Core 3.0 fonctionnera uniquement sur .NET Core 3.0
Et ne sera plus compatible avec la plateforme .NET Framework

Les mises à jour introduites par Microsoft dans la 3.0 de ASP.NET Core ont été conçues pour faciliter et accélérer les activités de développement, tout en palliant à certains manquements observés dans les précédentes versions.

Dans le cadre de cette évolution, certains sous-composants notables seront supprimés du framework partagé de ASP.NET Core dans sa version 3.0 : il s’agit notamment de Json.NET (Newtonsoft.Json) et de l’Entity Framework Core (Microsoft.EntityFrameworkCore.*).

Pièce jointe 424434

Microsoft continuera à fournir des packages pour assurer le support des éléments de ASP.NET Core qui, à l’instar du formateur JSON dans MVC, s’appuient encore sur les fonctionnalités de Json.NET. À l’avenir cependant, la firme de Redmond a prévenu qu’elle adoptera des API JSON comme solution par défaut sur ASP.NET Core. Entity Framework Core, pour sa part, sera livré sous forme de paquets NuGet « purs » à partir de cette version 3.0 de ASP.NET Core.

Pour s’assurer que ASP.NET 3.0 Core puisse pleinement tirer parti des améliorations apportées à .NET Core, Microsoft a annoncé que ASP.NET Core 3.0 fonctionnera uniquement sur la version 3.0 de .NET Core, mais pas sur la plateforme traditionnelle .NET Framework. ASP.NET Core pourra ainsi, à l’avenir, être considéré comme une composante de .NET Core.

De son côté, le Framework.NET ne devrait profiter que de très légères améliorations, la gestion de nouvelles langues notamment, pour préserver sa stabilité globale. La prise en charge complète de ASP.NET Core sur le Framework .NET est toujours d’actualité pour les utilisateurs de la version 2.1 LTS de .NET Core, une version dont la fin officielle du support est prévue pour le 21 aout 2021.

Microsoft semble désormais conscient du fait que l’usage de composants issus de tierces parties et/ou de codes open source performants et bien supportés par ses solutions peut procurer une valeur ajoutée certaine. La firme de Redmond estime, de ce fait, qu’il est fort probable qu’elle commence à fournir soutien et assistance à la communauté et à ses clients pour les aider à intégrer au mieux certaines de ces applications externes à sa solution ASP.NET Core.

Ce support se présentera sous différentes formes, incluant l’intégration de nouveaux paquets et API élaborés directement par Microsoft, des contributions apportées aux bibliothèques existantes, de la documentation accessible sur le site officiel de ASP.NET Core, etc.

« Alors que nous continuons à travailler sur la finalisation de la prochaine version mineure de ASP.NET Core, nous travaillons également sur des mises à jour majeures de notre prochaine version qui incluront des changements dans la façon dont les projets sont composés avec des frameworks, une intégration plus étroite de .NET Core ainsi qu’une intégration de tierces parties open source », a déclaré Microsoft.

Source : Blog Microsoft

Et vous ?

:fleche: Qu’en pensez-vous ?

Voir aussi

:fleche: Microsoft annonce la disponibilité de Visual Studio 2017 version 15.7 : un tour d'horizon des nouveautés de l'EDI
:fleche: Microsoft annonce la disponibilité de .NET Core 2.1 RC1, cette version peut déjà être utilisée en production
:fleche: .NET Core 3.0 offrira un support du développement d'applications de bureau, mais sur Windows uniquement
:fleche: Build 2018 : Microsoft annonce la disponibilité en préversion publique de VS Live Share, son extension de développement collaboratif en temps réel
05/12/2018, 14h10
Patrick Ruiz

1 pièce(s) jointe(s)

Microsoft annonce la sortie de la première préversion publique de .NET Core 3

Microsoft annonce la sortie de la première préversion publique de .NET Core 3
Et le passage en open source des frameworks « Windows Desktop »

On tient l’annonce d’un billet de blog de la firme de Redmond publié il y a peu : la première release publique de .NET Core 3 est disponible en téléchargement pour Windows, Mac et Linux. La nouvelle coïncide avec celle de la disponibilité de la première préversion de Visual Studio 2019 – version de l’environnement de développement intégré que le géant de la Tech. présente comme dotée du support de la nouvelle mouture de .NET Core.

Inutile de chercher dans les notes de version de .Net Core 3 pour savoir ce que cette release a dans le ventre. En octobre dernier, Microsoft a passé le mot quant à ce qui concerne les objectifs poursuivis. Jusqu’ici, la firme de Redmond a publié .NET Core sans prise en charge d’un framework d’interface utilisateur, ceci pour permettre une ouverture sur les plateformes Linux et Mac. Avec .NET Core 3, la firme de Redmond vient répondre à un desiderata formulé par des développeurs : la possibilité de faire usage du framework pour développer des applications de bureau. Désormais, Windows Presentation Foundation (WPF), Windows Forms et Entity Framework 6 (EF6) sont pris en charge pour permettre le développement de telles applications sur Windows. À noter que Microsoft a choisi l’approche brique séparée (Desktop packs) pour associer ces composants spécifiques à Windows au framework .Net Core 3.

Dans la keynote liée à ces développements, le géant de la Tech. a expliqué que l’un des avantages majeurs est de permettre des updates de .NET Core sans qu’il soit nécessaire de procéder à une mise à jour du système d’exploitation.

Pièce jointe 432318

Seulement, le principal intérêt de .NET Core est d’être multiplateforme et si on ajoute une framework de gestion des interfaces utilisateur, il doit tout autant pouvoir tourner sur des plateformes multiples. La firme de Redmond a peut-être une solution pour contourner cet obstacle. Parallèlement à l’annonce de la disponibilité de .Net Core 3, il faut noter que l’entreprise publie Windows Presentation Foundation (WPF), Windows Forms et WinUI en open source. Depuis novembre 2014, elle a engrangé près de 60 000 contributions de 3700 entités pour le framework .NET. Faisant suite à cette dernière manœuvre, on devrait voir des propositions de portage de ces composants sur Linux et Mac.

Source : msdn

Et vous ?

:fleche: Qu’en pensez-vous ?

Voir aussi :

:fleche: Vos applications Windows Forms et WPF sont-elles prêtes pour .NET Core 3.0 ? Microsoft veut s'en assurer et sollicite les développeurs
:fleche: .NET Framework 4.7.2 est disponible, avec le support de l'injection de dépendance dans les Web Forms et la sécurisation de cookies avec SameSite
:fleche: La préversion de la compilation hiérarchisée est disponible dans .NET Core 2.1, pour tirer le meilleur parti du démarrage et de l'exécution d'une app
:fleche: Microsoft annonce la sortie de .NET Core 2.1, avec de nombreux ajouts et améliorations qui viennent enrichir cet environnement
:fleche: .NET Core 3.0 offrira un support du développement d'applications de bureau, mais sur Windows uniquement
:fleche: Microsoft annonce la disponibilité de .NET Core 2.1 RC1, cette version peut déjà être utilisée en production
05/12/2018, 16h15
rt15

En langage Microsoft, ils ont complètement préparé le terrain pour une annonce de la fin des investissements sur le Framework .NET qui tombera officiellement d'ici 1 ou 2 ans.
Il va rejoindre Silverlight, IE et quelques autres dans la corbeille.
Le .NET Core semble être un bon remplaçant en tout cas : plus ouvert et plus portable.

Par contre concernant le portage de UWP, WPF ou des WinForms sur Linux et/ou Mac, même si ça risque d'intéresser des gens, ça représente sûrement beaucoup (trop ?) de boulot.
05/12/2018, 16h38
no2303

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.
05/12/2018, 16h40
François DORIN

Citation:

Envoyé par rt15

En langage Microsoft, ils ont complètement préparé le terrain pour une annonce de la fin des investissements sur le Framework .NET qui tombera officiellement d'ici 1 ou 2 ans.

Tout à fait. Et c'est même déjà presque le cas. Il suffit de voir que le Framework .NET ne supportera pas .NET Standard 2.1, mais restera en .NET Standard 2.0.

Citation:

Envoyé par rt15

Le .NET Core semble être un bon remplaçant en tout cas : plus ouvert et plus portable.

Et surtout plus léger. L'architecture est complètement différente, et il est beaucoup plus facile d'avoir plusieurs version de .NET Core cohabitant que plusieurs versions du Framework .NET (espace disque requis beaucoup plus léger).

Citation:

Envoyé par rt15

Par contre concernant le portage de UWP, WPF ou des WinForms sur Linux et/ou Mac, même si ça risque d'intéresser des gens, ça représente sûrement beaucoup (trop ?) de boulot.

Je doute clairement que cela se fasse. Malheureusement. Cela serait super, mais je reste très pessimiste sur ce point...
06/12/2018, 15h44
TheYoungGeek43

Rider intégrera bientôt .Net Core 3 ?
J’espère qu’ils feront enfin un wpf avec .Net Core pour pouvoir faire des logiciel cross platform 😉

Voir 40 message(s) de cette discussion en une page