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

Le , par Coriolan

176PARTAGES

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


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

Qu’en pensez-vous ?
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

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é
Microsoft annonce la diffusion de mises à jour cumulatives pour .NET Framework à compter de la mise à jour Windows 10 octobre 2018
PowerShell Core 6.1 est disponible : support de .NET Core 2.1, compatibilité avec les modules Windows, cmdlets et rendu Markdown et plus

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

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

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

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

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

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

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

alors oui wpf c'est différent à utiliser de winforms, mais la POO c'est aussi différent du code procédural d'il y a 25 ans
il faut prendre le temps d'essayer, de comprendre la philosophie, pour voir si ca correspond à notre besoin et si on apprécie le langage
pour passer d'un langage à un autre il faut souvent désapprendre des façons de faire, mais pour un nouveau qui se lance sur du XAML peut etre que ca sera aussi intuitif pour lui que controls.add l'était pour nous en winforms à nos débuts
2  0 
Avatar de Pol63
Expert éminent sénior https://www.developpez.com
Le 29/12/2018 à 14:34
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
2  0 
Avatar de François DORIN
Rédacteur https://www.developpez.com
Le 30/12/2018 à 22:02
Citation Envoyé par StringBuilder Voir le message
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.
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.
2  0 
Avatar de Bart-Rennes
Membre régulier https://www.developpez.com
Le 21/12/2018 à 8:56
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
2  1 
Avatar de Pol63
Expert éminent sénior https://www.developpez.com
Le 21/12/2018 à 11:00
Citation Envoyé par redcurve Voir le message
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 deprecated.

?
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)

Citation Envoyé par redcurve Voir le message
A noter que leur passage sur .net core 3 se fait simplement.

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à)
1  0 
Avatar de rt15
Membre confirmé https://www.developpez.com
Le 11/02/2019 à 17:40
Pardon mais en première lecture j'ai trouvé ces résultats suffisamment surprenant pour me demander si c'était pas pondu par une boîte, comment dire, légèrement influencée par M$.
Genre une boîte qui vend des produits basés sur ASP.NET et qui est toute contente d'avoir comme par hasard choisi la meilleur technologie.

Pour remettre dans le contexte, il y a quelques années, je me suis un peu intéressé à nodejs.
Avant cette étude, j'imaginais qu'un serveur en nodejs devais être au mieux 20 ou 30% plus lent qu'un serveur en C, C++ ou en Java.
Généralement le javascript peut difficilement espérer faire mieux, même exécuté par le V8 de Google qui est utilisé par nodejs.

Je me disais que les utilisateurs de nodejs acceptaient cette perte de performance.
Mais en fait pas du tout.
L'architecture d'un serveur nodejs est bien différente de la plupart des serveurs de l'époque.
Alors que beaucoup utilisaient (et utilisent encore) un thread par requête HTTP et parallélisaient les traitements sur différents coeurs, nodejs utilise un seul thread (du point de vue du développeur JS) et se base sur les entrées sorties asynchrones.

Le coeur de nodejs, c'est libuv, une bibliothèque écrite en C par le créateur de nodejs.
Cette librairie permet avant tout de faire en asynchrone les I/O sur les sockets et les disques.

En gros le thread principal ne fait que soumettre des demandes de "tâches" au système d'exploitation, du genre écrit moi ça sur telle socket.
Mais le thread n'attends pas la fin de la lecture ou de l'écriture : la demande de l'exécution d'une tâche n'est pas bloquante.
Au lieu de cela, le thread principal se met en attente sur un ensemble d’évènements tels que "fin de l'écriture" ou "il y a quelque chose à lire sur tel socket".
Le système réalise les tâches en arrière plan et notifie quand elles sont terminées.
Dès qu'un événement se déclenche, le thread principal va le traiter, généralement en soumettant de nouvelles tâches d'entrée/sortie, puis se remettre en attente d'un nouvel évènement.
De cette manière le thread principal a "très peu" de travail et peut gérer des quantités astronomiques de connections et de lectures/écritures sur disque.
Le fait d'avoir peu de threads est très avantageux par rapport à un serveur classique car quand le processeur change de thread, il faut qu'il remplace son contexte d'exécution et ça prend un certain temps.
Ce contexte et la pile associée au thread prend aussi de la place en mémoire.
Par contre le désavantage d'avoir un seul thread principal est que si on a besoin de faire une tâche gourmande en CPU et qu'on l'a fait en JS, ça va bloquer le thread principal et le serveur ne fera rien d'autre : il ne sera pas à l'écoute des évènements pendant ce temps là.

Le résultat c'est que pour certaines applications, un serveur nodejs ne vas pas être 20 ou 30% plus lent qu'une appli JEE. Le serveur nodejs peut battre le JEE à plate couture.
Mais ce n'est pas JS qui est plus rapide que le Java. C'est la librairie C libuv qui bat l'archi JEE.

Donc sachant la qualité de l'approche et de l'implémentation de nodejs dans ce domaine, j'ai été surpris que aspcore puisse écraser nodejs sur un "Best plaintext responses per second".

Qu'est ce qui peut expliquer une telle différence ?
En y regardant de plus près, a priori, le serveur web utilisé par ASP.NET Core dans ce benchmark s'appelle Kestrel (c'est celui par défaut).
https://github.com/TechEmpower/Frame...rks/Program.vb
(à noter qu'ils ont implémentés le benchmark en VB, pas en C#!)

Et devinez sur quoi est basé Kestrel à la base ? Sur libuv...

Depuis l'utilisation de libuv a été supprimé mais en fin de compte la nouvelle implémentation se base certainement sur epoll sous Linux et les Overlapped I/O sous Windows.
Kestrel s'appuie donc sur les mêmes fonctions systèmes que libuv.

En tout cas chapeau aux développeurs C/C++ de M$ pour leur résultat sur ce bench.
1  0 
Avatar de rt15
Membre confirmé https://www.developpez.com
Le 05/12/2018 à 16:15
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.
0  0 
Avatar de no2303
Membre régulier https://www.developpez.com
Le 05/12/2018 à 16:38
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.
0  0 
Sondage : quels sont les langages de programmation qui vont probablement disparaître
Siri enregistre les bagarres, les échanges avec les médecins, les ébats sexuels
Est-ce une grosse erreur de considérer la POO comme standard de l'industrie pour l'organisation des bases de code ?
Découvrez les dangers de MySQL et MariaDB, par Frédéric BROUARD (SQLpro)
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web