Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Patrick Ruiz

20PARTAGES

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

Source : Microsoft

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

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

Avatar de Eric80
Membre averti https://www.developpez.com
Le 11/11/2019 à 20:55
.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.
3  0 
Avatar de François DORIN
Expert éminent sénior https://www.developpez.com
Le 10/11/2019 à 10:39
Citation Envoyé par Patrick Ruiz Voir le message
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.
2  0 
Avatar de François DORIN
Expert éminent sénior https://www.developpez.com
Le 10/11/2019 à 19:06
Citation Envoyé par Pol63 Voir le message
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
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
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>
Citation Envoyé par Pol63 Voir le message
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.

Citation Envoyé par Pol63 Voir le message
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.

Citation Envoyé par Pol63 Voir le message
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 ?
2  0 
Avatar de redcurve
Membre confirmé https://www.developpez.com
Le 09/11/2019 à 22:34
.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.
1  0 
Avatar de gbegreg
Membre émérite https://www.developpez.com
Le 10/11/2019 à 15:36
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 !
1  0 
Avatar de defZero
Membre averti https://www.developpez.com
Le 10/11/2019 à 21:09
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.
1  0 
Avatar de Pol63
Expert éminent sénior https://www.developpez.com
Le 10/11/2019 à 16:25
Citation Envoyé par François DORIN Voir le message
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.

Citation Envoyé par François DORIN Voir le message
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 ^^

Citation Envoyé par François DORIN Voir le message
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.

Citation Envoyé par François DORIN Voir le message
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
0  0 
Avatar de LuNaTiC93
Nouveau Candidat au Club https://www.developpez.com
Le 10/11/2019 à 19:01
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.
0  0 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 10/11/2019 à 19:49
Citation Envoyé par Pol63 Voir le message
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?
0  0 
Avatar de StringBuilder
Expert éminent https://www.developpez.com
Le 11/11/2019 à 15:23
Citation Envoyé par Pol63 Voir le message
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.

Citation Envoyé par Pol63 Voir le message
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é.
0  0