De .NET Core 1 à .NET Core 3.0, retour sur l'évolution du Framework open source et multiplateforme
De Microsoft

Le , par Coriolan, Chroniqueur Actualités
Au début de ce mois, Microsoft a annoncé la sortie de la première préversion publique de .NET Core 3. Toutefois, l’éditeur n’a pas précisé quelles nouveautés sont incorporées dans cette release, à part le fait que des Frameworks Windows Desktop sont passés en open source, mais ça, on le savait déjà.


Dans un billet de blog, Scott Hunter, directeur de Program Management pour .NET, est revenu sur l’évolution de .NET Core depuis sa première mouture, avec un focus sur les technologies présentes sur la troisième itération majeure de la plateforme .NET Core. Pour rappel, s’agissant d’une préversion, les informations citées ici pourraient changer par la suite.

.NET Core 1

.NET Core a été développé avec pour objectif principal l’ouverture à d’autres plateformes dont Linux et OS X. Il comprend 2 parties complémentaires : CoreCLR, une implémentation d'exécution complète de CLR, la machine virtuelle qui gère l'exécution des programmes .NET et CoreFx, l’implémentation concrète de .Net Core sous la forme de plusieurs assemblies (DLL).

En 2016, la première version de .NET Core a vu le jour, le but étant de créer une première version de .NET qui soit à la fois open source et multiplateforme (Windows, macOS et Linux). Si Microsoft a fait ce choix, c’est pour cibler les utilisateurs qui n’utilisent que l’open source et les clients qui ont eu besoin d’exécuter leurs applications .NET sur des serveurs Linux. .NET Core est disponible sur GitHUb, et quiconque peut télécharger les sources, compiler le Framework ou encore contribuer. Outre ce détail, .NET Core a été conçu pour qu’il soit possible de tout passer par la ligne de commande, sans avoir besoin d’utiliser un EDI.

Prenant en compte les problèmes de compatibilité d’une installation globale de .NET Framework, .NET Core apporte le support de versions côte à côte, et la livraison d’un Framework faisant partie de l’application. Comme expliqué auparavant, 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 soient testées et prêtes.

.NET Core 2

La version 1 de .NET a ciblé en premier lieu les applications web et a supporté un nombre limité d’API .NET. Pour régler ce problème, Scott Hunter explique que le .NET Standard a été créé, ayant pour but de spécifier les API que tout environnement d’exécution doit implémenter pour que le code et les fichiers binaires puissent être partagés sur les plateformes et versions de .NET.

.NET Core 2 a été publié en juin 2017 avec le support de .NET Standard 2.0, ajoutant plus de 20 000 API au .NET Standard. Microsoft a introduit aussi le Windows Compatibility Pack, qui est un paquet NuGet qui inclut plusieurs API réservées à Windows comme : System.Drawing, System.DirectoryServices et d’autres. ASP.NET Core 2.0 a apporté Razor Pages et SignalR, deux frameworks qui manquaient dans .NET Core 1.0. L’Entity Framework a ajouté le support du lazy loading, une fonctionnalité populaire de Entity Framework.

Avec .NET Core 2, la performance de .NET a été considérablement améliorée, lui conférant une bonne place dans le classement des frameworks full-stack du marché.

.NET Core 3.0

.NET Core 3.0 est la prochaine version majeure de la plateforme .NET Core. Pour répondre à un desideratum formulé par les développeurs, Microsoft a introduit 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. Pour le développement web, il est désormais possible de créer des applications web clientes avec C# en utilisant Razor Components (Blazor auparavant). Et il inclut le support de C# 8.0 et .NET Standard 2.1. .NET Core 3.0 apporte aussi le support de scénarios impliquant l’Internet des objets et l’ARM64 qui vient compléter ARM32 déjà en place. En plus, il supporte de façon complète ML.NET, un framework d’apprentissage machine conçu pour les développeurs .NET.

ASP.NET Core 3

.NET Core 3.0 ne concerne pas seulement le desktop. Plusieurs nouveautés devront faire leur apparition pour le développement web. Blazor est le fruit d’une expérimentation qui a commencé cette année, il permet d’écrire des composantes d’UI web qui s’exécutent directement dans le navigateur sur un environnement .NET basé sur WebAssembly sans avoir à écrire une seule ligne de JavaScript, explique Scott Hunter. Pour .NET Core 3.0, Microsoft va intégrer le modèle de composant de Blazor dans ASP.NET Core. La firme appelle cette intégration Razor Components. Au début pour .NET Core 3.0, Razor Components va s’exécuter sur le serveur, soit en tant que composants routables ou bien utilisés à partir de Razor Pages et Views. Toutefois, les mêmes composants peuvent s’exécuter du côté client sur WebAssembly. Plus tard, Microsoft entend apporter des améliorations à la performance de l’environnement d’exécution avec le support de la compilation anticipée de code .NET à WebAssembly.

La feuille de route de .NET Framework et .NET Core

« .NET Framework est l’implémentation de .NET installée par plus d’un milliard de machines, et de ce fait doit garder la meilleure compatibilité possible » a écrit Hunter. « Pour cette raison, il avance à une cadence moindre comparé à .NET Core. Même les correctifs de sécurité et de bogues peuvent causer des dysfonctionnements dans les applications, car elles dépendent de caractéristiques antérieures.”

.NET Core est open source, multiplateforme, et évolue rapidement. À cause de sa nature côte à côte, il peut introduire des changements que Microsoft ne peut pas risquer d’appliquer dans .NET Framework. Ce qui veut dire que .NET Core va recevoir au fil du temps de nouvelles API et fonctionnalités de langages que .NET ne peut pas recevoir. Si vous avez des applications .NET Framework, Microsoft préconise qu’il n’est pas nécessaire de passer .NET Core si vous n’avez pas l’attention de profiter de ses fonctionnalités. La firme de Redmond assure que .net Framework fera toujours partie de Windows, mais dans le futur, .NET Core et .NET Framework vont incorporer de différentes fonctionnalités.

Source : msdn

Et vous ?

Qu’en pensez-vous ?
Comptez-vous porter des applications existantes vers .NET Core ?

Voir aussi

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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de Bart-Rennes 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
Avatar de redcurve redcurve - Membre confirmé https://www.developpez.com
le 21/12/2018 à 9:20
Citation Envoyé par Bart-Rennes Voir le message
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.

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
Avatar de micka132 micka132 - Membre expert 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?
Avatar de redcurve redcurve - Membre confirmé https://www.developpez.com
le 21/12/2018 à 9:41
Citation Envoyé par micka132 Voir le message
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 .
Avatar de Pol63 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à)
Avatar de François DORIN François DORIN - Responsable .NET & Magazine 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.
Avatar de Safirion Safirion - Candidat au Club https://www.developpez.com
le 21/12/2018 à 15:43
Bonjour tout le monde,
Y a t il eu des nouvelles quand a la possibilité de merger les dll dans un seul .exe en .net core 3 ?

En .net framework, il y a IL Repack, mais là, vu que ça compile en natif...
Avatar de rt15 rt15 - Membre confirmé https://www.developpez.com
le 21/12/2018 à 16:22
Citation Envoyé par redcurve Voir le message
win32 est un énorme problème pour windows
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 :
  1. Stabilité de l'API car elle doit rester compatible avec les (très) vieux logiciels, sans même une re-compilation de ceux-ci.
  2. Performance car si les appels au système d'exploitation sont lents, impossible de faire un logiciel performant.
  3. 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]
Avatar de jcop_fr jcop_fr - Membre à l'essai https://www.developpez.com
le 28/12/2018 à 15:27
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é...
Avatar de StringBuilder StringBuilder - Expert confirmé https://www.developpez.com
le 29/12/2018 à 10:34
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.
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web