Discussion :

[Patrick Ruiz]

Pourquoi devez-vous faire usage de .NET Core 3.0 pour le développement d’applications de bureau Windows ?
Microsoft se penche sur les avantages de cette approche

.NET Core 3.0 est disponible depuis la fin du mois de septembre de l’année qui tire à sa fin. Lorsque Microsoft a annoncé sa disponibilité future à mi-parcours de l’année 2018, c’était avec une nouvelle de taille pour les développeurs : la variante open source et multiplateforme de .Net Framework permettra de développer des applications de bureau Windows. En fait, l’entreprise répondait à des desiderata de ces derniers en s’écartant de sa posture d’origine, à savoir : mettre de côté les technologies du .Net Framework liées à Windows, ce, pour permettre une ouverture à d’autres plateformes dont Linux et macOS. De façon brossée, l’ouverture au développement d’applications de bureau Windows avec .NET Core 3.0 repose sur Windows Forms et Windows Presentation Foundation (WPF) dont Microsoft a effectué le portage.

Dans un billet de blog paru il y a peu, la firme livre des raisons additionnelles de son ouverture aux requêtes des développeurs. En sus, elle se penche sur les avantages de s’appuyer sur .NET Core 3.0 pour développer des applications de bureau Windows.

À mi-parcours du mois précédent, l’équipe .NET Core 3.0 de Microsoft a annoncé qu'elle a terminé avec le projet de portage de l'API .NET Framework sur la plateforme open source.

« À partir de maintenant, nous ne prévoyons plus de porter les API .NET Framework vers .NET Core. .NET Core 3.0 met un terme au projet de portage de l’API .Net Framework. Nous avons commencé dans .NET Core 1.0 avec un jeu d'API très minimal qui n'incluait que près de 18 000 des API de .NET Framework. Avec .NET Standard 2.0, nous avons essayé de rendre beaucoup plus viable le partage de code entre .NET Framework, .NET Core 3.0 et Xamarin, ce qui a permis d'étendre à environ 38 000 le jeu d'API .NET Framework disponibles dans .NET Core 2.0. Nous avons également mis en place le pack de compatibilité Windows, ce qui a augmenté les API .NET Core avec 21 000 unités ; résultat : près de 60 000 API supplémentaires. Dans .NET Core 3.0, nous avons ajouté WPF et WinForms, ce qui a augmenté le nombre d'API .NET Framework portées à .NET Core à plus de 120 000, ce qui représente plus de la moitié des API Framework. Il est également utile de souligner que nous avons ajouté environ 62 000 API à .NET Core qui n'existent pas dans .NET Framework. Si nous comparons les nombres totaux d'API, .NET Core possède environ 80 % des API de .NET Framework. », écrivait un responsable de la firme de Redmond.

La firme de Redmond va vers un futur centré sur .NET Core 3. En fait, les développements en cours marquent l’arrêt de l’évolution du .Net Framework rendu à la version 4.8. Ce dernier continuera néanmoins de bénéficier de prise en charge, mais la firme de Redmond se veut claire : elle axe ses travaux sur l’intégration de nouvelles technologies au sein du .NET Core.

Sur les bases posées avec .NET Core 3, Microsoft entend produire un environnement d’exécution .Net unique et une infrastructure partout. En d’autres termes, Microsoft va vers un seul .NET à l’avenir. Ce dernier pourra être utilisé pour cibler plusieurs (sinon toutes) plateformes : Windows, Linux, MacOS, iOS, Android, tvOS, watchOS et WebAssembly, etc. Ce futur se nomme .NET 5 – la prochaine version de .NET Core 3. La première préversion de .NET 5 sera disponible dans la première moitié de l’année à venir. La version finale est attendue en novembre 2020. Microsoft prévoit ensuite de publier une version majeure de .NET une fois par an, ce, tous les mois de novembre.

C’est donc en quelque sorte pour apporter des améliorations à Windows Forms et Windows Presentation Foundation (WPF) que Microsoft a effectué leurs portages respectifs vers .NET Core.

« Lors du développement d'applications de bureau, vous ne remarquerez pas beaucoup de différence entre les versions .NET Framework et .NET Core de WPF et Windows Forms. Une partie de notre effort consistait à fournir une parité fonctionnelle entre ces plateformes dans le domaine des applications de bureau et à améliorer l'expérience .NET Core à l'avenir », écrit Microsoft.

C’est aussi pour permettre aux développeurs d’applications de bureau Windows de profiter des fonctionnalités de .Net Core susceptibles d’améliorer leurs applications que la firme s’est lancée dans cette voie.

« Pour améliorer les piles de développement d'applications de bureau Windows et permettre aux développeurs .Net de bénéficier de toutes les mises à jour de l'avenir, nous avons apporté Windows Forms et WPF à .NET Core. Ils resteront toujours des technologies Windows uniquement parce qu'il y a des dépendances étroitement liées aux API Windows. Mais .NET Core, en plus d'être multiplateforme, possède de nombreuses autres fonctionnalités qui peuvent améliorer les applications de bureau », ajoute l’entreprise.

Retour sur les avantages de l’approche

En présentant .NET Core il y a un an, l’éditeur a listé un certain nombre d’avantages à s’appuyer sur la version 3 pour le développement d’applications de bureau :

• versions côte à côte de .NET Core qui supportent Winforms et WPF : Avant le lancement de cette version, il ne pouvait 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 casse 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 avoir été testées ;
• intégration de .NET Core directement dans une application : Puisqu’une seule version de .NET Framework pouvait être installée sur une machine, il était impératif d’installer la dernière version pour tirer avantage d’une nouvelle fonctionnalité du framework ou du langage. Avec .NET Core, il est possible d’intégrer le framework à une application. Cela permet de tirer parti de la dernière version, fonctionnalités et API sans avoir à attendre l’installation du framework ;
• bénéfice 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.

Dans sa dernière note d’information, la firme étend la liste :

• Tailles d’exécutables plus petites : Cette possibilité offerte par .NET Core 3 s’appuie sur une fonctionnalité d’analyse de code dénommé Linker. Elle inclut à une application .NET autonome uniquement les portions de .NET Core qui lui sont nécessaires ;
• amélioration des performances du runtime : NET Core offre de nombreuses optimisations de performance par rapport à .NET Framework. De façon plus précise, les applications de bureau qui dépendent de façon importante des E/S de fichiers, du réseau et de l'exploitation des bases de données verront probablement leur performance s'améliorer pour ces scénarios. Certains domaines dans lesquels vous ne remarquerez peut-être pas beaucoup de changements sont les performances de rendu de l'interface utilisateur ou les performances de démarrage de l'application.

Dernier état des lieux

Certes, .NET Core 3 ouvre la voie au développement d’applications de bureau, mais il y a des détails à prendre en compte avant d’en faire usage. Seules les applications WPF bénéficient d’une prise en charge totale. Visual Studio 2019 16.3 prend en charge la création d'applications WPF qui ciblent .NET Core. Cela inclut de nouveaux templates, un concepteur XAML (similaire au concepteur XAML existant qui cible .NET Framework) et XAML Hot Reload. Le portage du runtime Windows Forms pour sa part est effectué dans son entièreté. Ce sont les travaux de mise sur pied du concepteur Windows Forms qui se poursuivent. « Il devrait être prêt d’ici le quatrième trimestre de l’année à venir », écrit Microsoft. Toutefois, il est en préversion et disponible en téléchargement séparé en tant qu’extension Visual Studio.

En plus de Windows Forms et WPF, le package System.Windows.Forms.DataVisualization (qui inclut le contrôle permettant de générer des graphiques) est disponible pour .NET Core. Il est donc maintenant possible d’inclure ce contrôle dans des applications .NET Core WinForms.

Et vous ?

Que pensez-vous de .Net Core 3 ? Qu'en attendez-vous ?

En quoi est-il une bonne (ou une mauvaise) alternative à .NET Framework ?

Voir aussi :

.NET Core 3.0 offrira un support du développement d'applications de bureau, mais sur Windows uniquement
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
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
De .NET Core 1 à .NET Core 3.0, retour sur l'évolution du Framework open source et multiplateforme de Microsoft
.NET Core 3.0 Preview 4 est disponible et s'accompagne d'une MàJ de la compilation hiérarchisée ainsi que du contrôle WinForms Chart
Avec .NET 5, Microsoft voudrait produire un environnement d'exécution .NET unique et une infrastructure utilisable partout
Microsoft confirme que la version générale de .NET Core 3.0 sera disponible durant la .NET Conf 2019 et en profite pour publier .NET Core 3.0 RC1

[defZero]

Franchement épaté par MS sur ce coups là.
Ils arrivent à faire jeux égale, voire moins bien que Google, en y mettant plus de temps et d'effort.

Maintenant que Dart/Flutter est sortie (et ce montre intéressant avec sa FFI) et que les Electrons et compagnies ce sont démocratisés, je suis désolé, mais je ne vois plus l'intérêt de .Net/Java, pour le dev multi-plateform (pour du dev spécifique ou de la TMA on peut continuer d'en parler).

Je pense que MS/Oracle ont loupés une palanquée d'occasions dans le secteur et qu'ils essaient de ce refaire (MS de façon plus propre qu'Oracle ).

Revenons sur les avantages qu'ils nous annonces :

Versions côte à côte de .NET Core qui supportent Winforms et WPF :
Avant le lancement de cette version, il ne pouvait 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 casse 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 avoir été testées ;

C'est bien un progrès, mais la limitation d'origine ne venait que de MS, donc venir s'en venter après X années d'existence .
De plus en allant jeter un coups d’œil à la doc :

Version selection occurs:

When you run an SDK command, the SDK uses the latest installed version.
When you build an assembly, target framework monikers define build time APIs.
When you run a .NET Core application, target framework dependent apps roll forward.
When you publish a self-contained application, self-contained deployments include the selected runtime.

Ça commence à devenir une usine à gaz pour du multi-plateforme, entre les versions d'APIs cibles de compilation et celles qui sont présentes sur les plateformes cibles ou qui sont embarqué dans l'App, je prédit une avalanche d'appel au SAV avec des messages d'incompatibilités d'APIs et/ou de sécurités.

intégration de .NET Core directement dans une application :
Puisqu’une seule version de .NET Framework pouvait être installée sur une machine, il était impératif d’installer la dernière version pour tirer avantage d’une nouvelle fonctionnalité du framework ou du langage.
Avec .NET Core, il est possible d’intégrer le framework à une application.
Cela permet de tirer parti de la dernière version, fonctionnalités et API sans avoir à attendre l’installation du framework ;

Oui, mais ça bloque également un gros avantage d'avoir le Runtime indépendant des Apps, les MàJ de sécurités.
Si l'App n'est pas mis à jours et qu'elle est essentiel à ma société, je me retrouve le cul dans l'eau, avec sur un serveur de Prod une App potentiellement vulnérable et pas de moyens de patcher le Runtime indépendamment.
Après, vous me direz qu'on pouvait très bien ce retrouver avec une version du Runtime incompatible avec une App sur sont serveur de Prod.
Mais personnellement, j'avais tendance à faire une App, un Runtime, une VM/Conteneur, là ça ne servira plus à rien, si les failles sont compilé en statique.

bénéfice 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.

...Le gros avantage de .Net Core est ...l'utilisation de .Net Core
Et en ce qui concerne WinForms & WPF disponible uniquement sur Windows, car trop dépendent des APIs Windows, je dit banco .
C'est vrai que d'implémenter une nouvelle API de GUI multiplateforme (tant qu'à tout renouveler comme ils le prétendent, Why Not ?), ça aurait été du travail c'est sur, d’ailleurs ça n’existe nul part .

Tailles d’exécutables plus petites :
Cette possibilité offerte par .NET Core 3 s’appuie sur une fonctionnalité d’analyse de code dénommé Linker.
Elle inclut à une application .NET autonome uniquement les portions de .NET Core qui lui sont nécessaires ;

A partir du moment ou tu pratique la compilation statique, forcement, tu peut te permettre d'optimiser et de ne plus embarqué les partis inutile.
Mais ça n'as rien de nouveau ça , c'est une conséquence logique de leur possibilité d’embarqué le runtime/assembly en standalone.

amélioration des performances du runtime :
NET Core offre de nombreuses optimisations de performance par rapport à .NET Framework.
De façon plus précise, les applications de bureau qui dépendent de façon importante des E/S de fichiers, du réseau et de l'exploitation des bases de données verront probablement leur performance s'améliorer pour ces scénarios.
Certains domaines dans lesquels vous ne remarquerez peut-être pas beaucoup de changements sont les performances de rendu de l'interface utilisateur ou les performances de démarrage de l'application.

Encore une fois, tout est lié à leur liaisons statique avec des runtimes/assemblies, donc rien de nouveau.

Si je devais comparer les annonces de MS pour .Net, je les mettrais bien en parallèle de ce qu'a fait Apple avec le Runtime Swift 5 ou Oracle avec GraalVM.
Ils ce tirent tous la bourre sur des problèmes qui sont présent depuis longtemps dans les langage compilé managé et que leurs plateformes étaient censées résoudre avec simplicité.

Du coup, je vois de moins en moins l'intérêt de faire du .Net/Java/Swift, s'il ne font qu'apporter plus de complexité par rapport à des langages compilés qui ont eux aussi continués d'évoluer dans le bon sens (C++11, Object Pascal, C11 et même des petit nouveaux comme Nim, Zig, Kit, Odin, Go )
Et pourtant je suis un grand fan de ne plus avoir à manipuler à la main les mémoires de mes programmes, mais je finit par me dire que c'est un moindre mal en comparaison à ce que les alternatives nous proposes.

Enfin, l'important reste d'utiliser le bon outil pour le bon projet, même si je regrette la complexification des plateformes qui est en train d'émerger.

[redcurve]

.Net était déjà une très bonne technologie mais .Net Core va vraiment plus loin. Je considère le framework .net comme obsolète depuis 2015 pour ma part, je ne fais plus rien avec depuis début 2017.

Il ne manque de WinUI 3 pour avoir de la GUI multiplate-forme, le travail a déjà commencé y'a du code et de la PR à faire.

[denisys]

.NET Core 3 , n'est pas multiplateforme!
Une application WPF ou Windows Forms , ne peut être développer sur une Ubuntu.
Ni être executé !

[François DORIN]

versions côte à côte de .NET Core qui supportent Winforms et WPF : Avant le lancement de cette version, il ne pouvait 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 casse 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 avoir été testées ;

Je suis très surpris de cette remarque. Une seule version du Framework .NET sur une machine ? Je viens de compter, et sur ma machine, j'en ai.. 13 ! Microsoft a toujours permis l'utilisation conjointe de plusieurs Framework .Net. Parfois le changement ne concerne que les bibliothèques, parfois, le moteur (CLR) également. Et il est possible de préciser dans le .config de l'application la version à utiliser.

Enfin, même si j'apprécie énormément le travail de Microsoft sur .Net et notamment .Net Core, le portage tel qu'il est fait actuellement des technologies WinForm et WPF est juste inutile. Ces technologies ne sont disponibles que sous Windows (rompant ainsi le portage sur d'autres plateforme, but initial de .Net Core). Et surtout, ne seront pas disponible sur d'autres plateforme (Microsoft refuse les patch visant le multiplateforme pour ces techno).

La possibilité de faire des GUI sous .Net Core est très demandé. Et nous n'avons pas tous envie d'utiliser des environnements comme Electron, qui sont des gouffres en consommation de ressources, en plus d'introduire encore plus de techno dans nos applications (HTML, JS, CSS).

Il y a un réel besoin pour une couche GUI. Aujourd'hui, des solutions véritablement utilisables, il n'y en a pas. Il y en a quelques unes vers lesquelles on peut se tourner et qui semblent prometteuses, mais toujours, au mieux, en Beta (par exemple, AvaloniaUI). Xamarin.Forms n'est pas encore non plus prêt pour le Desktop. Gtk# (binding de Gtk comme son nom l'indique), n'est malheureusement qu'une blague quand il s'agit de faire du multiplateforme, avec des comportements différents selon les plateformes, et des comportements qui peuvent changer d'une version (même mineure !) à l'autre.

Je regrette qu'il n'y ait pas eu un rapprochement entre .Net Core et Mono. Avoir un WinForm utilisable en multiplateforme aurait véritablement été une grande avancée pour l'environnement .Net Core.

[gbegreg]

Intéressant mais Microsoft a trop souvent mis en avant certaines technos par le passé pour les abandonner quelques temps plus tard...
Pour le développement d'applications de bureau et mobiles multi plate-forme, je reste sous Delphi. Quant aux applications basées sur Electron, il n'y a pas photo : elles sont bien trop lourdes et consommatrices de ressource !

[Pol63]

Je suis très surpris de cette remarque. Une seule version du Framework .NET sur une machine ? Je viens de compter, et sur ma machine, j'en ai.. 13 ! Microsoft a toujours permis l'utilisation conjointe de plusieurs Framework .Net. Parfois le changement ne concerne que les bibliothèques, parfois, le moteur (CLR) également. Et il est possible de préciser dans le .config de l'application la version à utiliser.

Il est possible de dire la version minimum qu'on souhaite, mais depuis le fx4 ca prend le plus récent je pense, une app qui cible 4.5 et si le 4.8 est installé alors c'est le 4.8 qui sera utilisé vu qu'il n'y a que celui là
Il y a un an MS a fait une maj de Windows avec une maj du framework et une de nos applis s'est mise à planter car il y avait une modif sur sqlconnection (bug et/ou regression)
Je n'ai pas eu le détail de si c'était une maj d'un framework existant ou ou une version plus récente qui a été installé mais ca reste problématique.
Le fait d'intégrer le framework permet d'éviter ce problème, c'est surtout en ce sens que ce que MS a fait est pas mal (Après on passe à environ 100Mo l'exe WPF …)
Néanmoins comme précisé par un autre je crois, ca sera maintenant au développeur de se tenir au courant des maj de sécurité qu'il doit déployer.

La possibilité de faire des GUI sous .Net Core est très demandé. Et nous n'avons pas tous envie d'utiliser des environnements comme Electron, qui sont des gouffres en consommation de ressources, en plus d'introduire encore plus de techno dans nos applications (HTML, JS, CSS).

Certains disent que le client lourd est mort depuis longtemps et que le web est partout ^^

Xamarin.Forms n'est pas encore non plus prêt pour le Desktop.

j'ai cru voir en effet qu'ils essayaient de pouvoir cibler Windows via wpf, mais pour moi ce n'est pas une solution, Xamarin est vraiment limité par rapport à wpf, c'est beaucoup moins plaisant à utiliser.

Je regrette qu'il n'y ait pas eu un rapprochement entre .Net Core et Mono. Avoir un WinForm utilisable en multiplateforme aurait véritablement été une grande avancée pour l'environnement .Net Core.

le mieux serait un nouveau Framework graphique fortement inspiré de wpf (qui n'est pas parfait non plus) qui serait totalement cross plateform, et qui remplacerait Xamarin au passage

après moi je suis content de l'intégration de wpf dans .net core
au passage il a été rendu open source, et a donc des chances d'évoluer à nouveau

[LuNaTiC93]

Maintenant que Dart/Flutter est sortie (et ce montre intéressant avec sa FFI) et que les Electrons et compagnies ce sont démocratisés, je suis désolé, mais je ne vois plus l'intérêt de .Net/Java, pour le dev multi-plateform (pour du dev spécifique ou de la TMA on peut continuer d'en parler).

C'est un débat sans fin, on utilise avant tout un langage ou un écosystème par envie ou confort syntaxique et non par nécessité, sinon pourquoi google aurait développé un moteur d'éxécution js pour serveur alors qu'on pouvait déjà le faire en PHP ou autre.
Le JavaScript ne remplacera jamais le C# ou le Java ou tout autre langage historique. Et utiliser électron pour faire des app c'est tout sauf une bonne idée, les performances sont médiocres.

[François DORIN]

Il est possible de dire la version minimum qu'on souhaite, mais depuis le fx4 ca prend le plus récent je pense, une app qui cible 4.5 et si le 4.8 est installé alors c'est le 4.8 qui sera utilisé vu qu'il n'y a que celui là

Il est bien possible de préciser la version souhaitée.

Par exemple, ce code :

Code Csharp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
class Program
	{
		static void Main(string[] args)
		{
			List<int> list = new List<int>() { 1, 2, 3 };
			list.ForEach(i =>
			{
				if (i < 3) 
				{	
					list.Add(i + 1); 
				}
			});
		}

fonctionne sans problème avec .Net 4, mais pas .net 4.5 (exception). Pour comprendre pourquoi, c'est juste que le comportement de la méthode ForEach s'est rapproché de celle de l'instruction foreach, qui génère une erreur si la collection est modifiée. Préciser le framework a utilisé permet de faire fonctionner le programme. Mais il faut préciser la version voulu via le fichier app.config

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
    </startup>
</configuration>

Il y a un an MS a fait une maj de Windows avec une maj du framework et une de nos applis s'est mise à planter car il y avait une modif sur sqlconnection (bug et/ou regression)
Je n'ai pas eu le détail de si c'était une maj d'un framework existant ou ou une version plus récente qui a été installé mais ca reste problématique.
Le fait d'intégrer le framework permet d'éviter ce problème, c'est surtout en ce sens que ce que MS a fait est pas mal (Après on passe à environ 100Mo l'exe WPF …)

Je suis d'accord, ça reste problématique. J'ai eu une fois le cas aussi, avec le composant CrystalReport. Après une mise à jour windows, la génération d'un pdf était passé de quelques secondes à 10min, avec occupation d'un core à 100%. Autant dire que le système tombait très vite !
Mais c'est bien la seule fois où j'ai rencontré un problème de ce type.

Néanmoins comme précisé par un autre je crois, ca sera maintenant au développeur de se tenir au courant des maj de sécurité qu'il doit déployer.

Et aux utilisateurs de l'installer également. On remplace un problème par un autre. Pour ma part, je préfère privilégier la sécurité et avoir une application qui plante, qu'une application qui marche mais qui est trouée et qui va servir de vecteur d'attaque.

Certains disent que le client lourd est mort depuis longtemps et que le web est partout ^^

Les mêmes qui disent que les SGBD relationnels étaient mort avec l'arrivé des bases NoSQL ? Et encore après avec la Blockchain, solution universelle pour tout ?

[micka132]

Le fait d'intégrer le framework permet d'éviter ce problème, c'est surtout en ce sens que ce que MS a fait est pas mal (Après on passe à environ 100Mo l'exe WPF …)
Néanmoins comme précisé par un autre je crois, ca sera maintenant au développeur de se tenir au courant des maj de sécurité qu'il doit déployer.

Est-ce que ça ne revient tout simplement pas au même de mettre "copy local" à true sur toute les références utilisées?

[defZero]

C'est un débat sans fin, on utilise avant tout un langage ou un écosystème par envie ou confort syntaxique et non par nécessité, ...

@ LuNaTiC93

Tu développe dans un environnement professionnel ?
Parce que je peut t'affirmer, d'expérience et en dehors de toute veille technologique, que le développeur final dans une équipe est rarement celui qui choisit quoique ce soit dans sa stack pour un projet.
Au mieux on le consulte pour avis, avec la portée que ça peut avoir.
Dans tous les cas, c'est le chef de projet ou un autre qui va fixer ce choix cornélien pour toi et tes collègues .

... sinon pourquoi google aurait développé un moteur d'éxécution js pour serveur alors qu'on pouvait déjà le faire en PHP ou autre.

@ LuNaTiC93

Mais Google n'as rien développer.
C'est Ryan Lienhart Dahl qui a mixer le moteur d’exécution JS de Chromium, alias V8, avec libuv pour profiter de leurs propriétés respectives en asynchrone et qu'il trouvait intéressante pour la programmation côté serveur.
Et puis dire que l'on peut faire la même chose, aussi simplement, en PHP et en NodeJS, ce n'est pas vrai (ni à l'époque, NodeJS datant de 2009-2010).

Le JavaScript ne remplacera jamais le C# ou le Java ou tout autre langage historique.

@ LuNaTiC93

Oui, parce que chaque langage est sa propre niche en soit.
Un outil qui excelle dans un/des domaine/s et moins/pas du tout dans les autres.
D'où le faite que je trouve la proposition de MS avec .Net Core largement survendu au mieux.

Et utiliser électron pour faire des app c'est tout sauf une bonne idée, les performances sont médiocres.

@ LuNaTiC93

Là dessus, je suis tout a fait d'accord, concernant les performances médiocres des solutions basé sur un navigateur embedded, en comparaison avec du dev natif.
Mais il faut avouer que pour du multi-plateforme, je n'est rien vue de plus simple à mettre en place.
Sans compter que toutes les applications n'ont pas forcement besoin de performances et que des dev JS, tu en trouveras à la pelle.

[esperanto]

Enfin, même si j'apprécie énormément le travail de Microsoft sur .Net et notamment .Net Core, le portage tel qu'il est fait actuellement des technologies WinForm et WPF est juste inutile. Ces technologies ne sont disponibles que sous Windows (rompant ainsi le portage sur d'autres plateforme, but initial de .Net Core). Et surtout, ne seront pas disponible sur d'autres plateforme (Microsoft refuse les patch visant le multiplateforme pour ces techno).

Donc en gros Microsoft continue le foutage de gueule: après s'être empressés de soumettre C# à l'ECMA pour damer le pion à Java - mais en excluant WForms et WPF pour être sûr que la majorité des utilisateurs seront sous Windows - voila qu'ils font semblant de le rendre libre avec .NET Core, alors qu'en réalité c'est plus proche d'un Open Source avec tivoisation puisqu'il n'y a guère qu'en forkant (donc en abandonnant le nom .NET core) qu'on peut réellement le modifier.

Certains disent que le client lourd est mort depuis longtemps et que le web est partout ^^

Même plus, la cible à la mode en 2019 ce sont les clients lourds... mais sur téléphone mobile.
Autrefois, Java proposait les applets comme un sous-ensemble du client lourd AWT/Swing, volontairement limité sauf signature pour raisons de sécurité.
Aujourd'hui, Flutter ou React voient le client sur desktop comme un sous-ensemble limité (volontairement ou pas) du client sur téléphone mobile.

Et question sécurité, on renverse les rôles: ce qui fout les boules à nos DSI aujourd'hui, c'est l'idée qu'on puisse encore avoir des applications en local, voire même des fichiers en local qui ne soient pas synchronisés avec le serveur central via le répertoire Roaming...

[StringBuilder]

Il y a un an MS a fait une maj de Windows avec une maj du framework et une de nos applis s'est mise à planter car il y avait une modif sur sqlconnection (bug et/ou regression)
Je n'ai pas eu le détail de si c'était une maj d'un framework existant ou ou une version plus récente qui a été installé mais ca reste problématique.
Le fait d'intégrer le framework permet d'éviter ce problème, c'est surtout en ce sens que ce que MS a fait est pas mal (Après on passe à environ 100Mo l'exe WPF …)
Néanmoins comme précisé par un autre je crois, ca sera maintenant au développeur de se tenir au courant des maj de sécurité qu'il doit déployer.

En tant qu'intégrateur de solution logicielles chez des clients, je peux vous assurer qu'il y a des millions de bonnes raisons pour que le lien entre le développeur et la machine de l'utilisateur final soit rompu : arrêt du contrat de maintenance, utilisation d'une version plus supportée, disparition de l'éditeur, etc.

De la même manière, il est quasi impossible pour un développeur de prévoir tous les contextes d'utilisation de ses logiciels : quelle n'est pas la surprise des éditeurs quand je leur explique que leur outil fonctionne très bien quand on les branche avec un SQL Server sous Linux... ou leur application fonctionne avec la dernière version de Windows ou d'Office qui sont en versions Insider...

Par conséquent, il me semble bien plus logique que ce soit l'utilisateur final qui vérifie la compatibilité de ses programmes avant de mettre à jour son OS ou un framework.

Permettre de mettre en bundle une version embarquée du framework cible devrait :
- être la toute dernière chance de la dernière des solutions (après même avoir échoué à utiliser une VM faisant tourner la bonne version du Framework)
- devrait être possible après compilation et ouverte à l'utilisateur final, sans nécessiter quelle que recompilation que ce soit. en effet, on a généralement les soucis de compatibilité quelques années après la sortie du programme, quand les versions des framework en question ne sont plus maintenues, pas le jour où le programme sort et qu'il a été testé sur toutes les plateforme du marché.
En effet, quand on a un ERP utilisé par 5000 personnes qui gère tous les process critiques de l'entreprise, tu peux pas te lancer tous les 15 jours (rythme de sortie des patchs correctifs) dans des projets de 2 ans de migration... Il faut pouvoir faire évoluer la plateforme sans devoir faire évoluer le produit.
Et à ce jour, je ne connais aucun éditeur qui s'amuse à proposer d'anciennes versions recompilées pour supporter des évolutions de la plateforme... L'époque des Services Packs sur 5 versions différentes est révolu, maintenant chaque éditeur ne distribue que la toute dernière version de son produit, et ne fait aucun correctif ou évolutif sur les versions antérieures.

le mieux serait un nouveau Framework graphique fortement inspiré de wpf (qui n'est pas parfait non plus) qui serait totalement cross plateform, et qui remplacerait Xamarin au passage

Quand UWP est sorti, j'ai bêtement cru que c'était la version 1 de ce Framework multiplateforme... Je ne comprends toujours pas son abandon... il aurait simplement porté sous Android ou iOS et aujourd'hui tous les programmes sur nos Smartphones seraient tout UWP... et probablement les Windows Phone auraient réussi à prendre des parts de marché.

[Eric80]

.NET Core 3.0 est intermédiaire, on attends surtout 3.1 qui sera LTS.
C'est beaucoup plus rassurant de lancer un projet avec un framework en LTS que un dont le support expire au bout de 8 mois et donc requière plus de boulot pour les MAJ.
https://dotnet.microsoft.com/platfor...cy/dotnet-core
3.1 est désormais prévu pour décembre (vs novembre initialement)

Tous les projets en .net core 2.x devront ainsi passer à 3.1 au 1er semestre 2020.

[denisys]

.NET Core 3.0 est intermédiaire, on attends surtout 3.1 qui sera LTS.
C'est beaucoup plus rassurant de lancer un projet avec un framework en LTS que un dont le support expire au bout de 8 mois et donc requière plus de boulot pour les MAJ.
https://dotnet.microsoft.com/platfor...cy/dotnet-core
3.1 est désormais prévu pour décembre (vs novembre initialement)

Tous les projets en .net core 2.x devront ainsi passer à 3.1 au 1er semestre 2020.

Finalement …
Il vaut, peut être mieux attendre la sortie de la version 4.5 !
Moins de bugs, moins de plâtre a avaler !!
Non ???

[impopia]

.NET = lenteur, contournement, source de bugs. C'est une partie géante des versions Windows depuis ~Vista. Je trouve que "good old" Windows API est beaucoup mieux. Pour les amateurs de C++ il y a des bibliothèques qui sont vraiment beaucoup moins encombrantes. 18000 APIs = une partie très basique ?... 18000 ?! Ça résume tout. Windows serait beaucoup mieux sans .NET.

[redcurve]

Donc en gros Microsoft continue le foutage de gueule: après s'être empressés de soumettre C# à l'ECMA pour damer le pion à Java - mais en excluant WForms et WPF pour être sûr que la majorité des utilisateurs seront sous Windows - voila qu'ils font semblant de le rendre libre avec .NET Core, alors qu'en réalité c'est plus proche d'un Open Source avec tivoisation puisqu'il n'y a guère qu'en forkant (donc en abandonnant le nom .NET core) qu'on peut réellement le modifier.



Même plus, la cible à la mode en 2019 ce sont les clients lourds... mais sur téléphone mobile.
Autrefois, Java proposait les applets comme un sous-ensemble du client lourd AWT/Swing, volontairement limité sauf signature pour raisons de sécurité.
Aujourd'hui, Flutter ou React voient le client sur desktop comme un sous-ensemble limité (volontairement ou pas) du client sur téléphone mobile.

Et question sécurité, on renverse les rôles: ce qui fout les boules à nos DSI aujourd'hui, c'est l'idée qu'on puisse encore avoir des applications en local, voire même des fichiers en local qui ne soient pas synchronisés avec le serveur central via le répertoire Roaming...

Je vois pas comment Microsoft pourrait soumettre Winform ou WPF à l'ECMA... C'est comme dire on va balancer Logstash à l'ECMA ^^ ça n'a aucun sens.

.Net Core est sous license MIT vous voulez quoi d'autre ? Si vous voulez y ajouter un truc vous avez deux choix faire un fork ou soumettre du code sur leur repo, code qu'ils ne sont pas obligés d'accepter. Vu la quantité de PR acceptés s'ils prennent pas votre truc c'est que ou votre modification n'a aucun sens, ou alors il change complètement le fonctionnement de l'existant à ce moment il faut trouver des pistes pour opt-in etc.