Déplacement vers les applications de bureau dans .NET Core / .NET 5

.NET 5 est sorti depuis plus de quatre mois maintenant (.NET Core 3 depuis un an et demi). Qu'y a-t-il dans l'une ou l'autre des plates-formes pour le développeur de bureau? La réponse courte est "Assez pour envisager de créer votre prochaine application de bureau." Réponse plus longue: «… et envisagez de migrer les applications existantes.»

Vous créez des applications de bureau dans .NET Framework et vous vous demandez si vous devriez les déplacer vers .NET Core ou .NET 5. Une partie de votre problème est que les applications de bureau que vous avez créées sur .NET Framework ont ​​toute cette fonctionnalité «fonctionnelle» que les utilisateurs aiment tant. Avez-vous vraiment besoin d'adopter une nouvelle plate-forme de bureau?

Ayant posé cette question, je dois souligner que, dans .NET Core et .NET 5, votre expérience en tant que développeur WPF et Windows Forms n'est pas si nouvelle »: WPF est entièrement pris en charge dans .NET Core, tout comme Windows Forms (y compris le Concepteur Windows Forms, qui a été publié en mai dernier). Lorsqu'il s'agit de créer des applications, vous constaterez que vos doigts savent déjà quoi faire. Vous n’allez pas être ralenti si vous démarrez votre prochaine application dans .NET 5.

Mais ce n’est pas la bonne question. La vraie question est de savoir s'il y a quelque chose dans le développement de bureau pour .NET Core / .NET 5 qui vous incite à vouloir changer.

Les gains

Pour commencer, passer à .NET Core peut résoudre tout problème de performance que vous pourriez avoir. Grâce aux améliorations apportées aux bibliothèques de classes de base .NET, vous devriez voir tous les éléments qui font glisser les applications d'entreprise classiques s'exécuter plus rapidement: base de données, réseau et activité d'E / S de fichiers. Dans .NET 5, même les rafraîchissements d'écran devraient être plus rapides. Et vous n'avez rien à faire pour obtenir ce gain, sauf à créer votre application dans .NET Core ou .NET 5.

Vous bénéficierez d'un soulagement supplémentaire lors du déploiement de votre application. Si vous voulez vous assurer que la bonne version de .NET Core existe sur l'ordinateur avec votre application, vous pouvez regrouper votre application et les composants .NET Core requis dans un seul fichier exe (et, soit dit en passant, uniquement les composants .NET Core nécessaires dont votre application a besoin doivent être regroupés dans ce fichier). Enfin, vous pouvez simplement copier votre fichier sur un nouvel ordinateur et vous attendre à ce que votre application s’exécute.

Et, même si ce n’est peut-être pas votre première pensée en ce qui concerne les «nouveaux éléments de bureau sympas», si vous voulez utilisez les dernières versions de C #, C # 8 et 9, vous devez passer à .NET Core / .NET 5. Les nouvelles fonctionnalités de C # 8/9 incluent la possibilité d'ajouter des implémentations par défaut pour les méthodes lors de la définition d'une interface (ce que l'on appelle des «traits ”Dans d'autres plates-formes), créez des types de référence immuables (enregistrements) et écrivez du code plus simple (en omettant les types dans les nouvelles expressions, en utilisant des expressions de niveau supérieur). Dans un monde de plus en plus asynchrone, les dernières versions de C # vous permettent également de créer des collections qui fonctionnent avec une boucle asynchrone foreach et de lancer une instruction plus flexible à l'aide de l'instruction qui vous permet de disposer des objets de manière asynchrone (qui fournit également un code plus simple lors de la mise en place d'un bloc using pour l'élimination automatique).

Les nouvelles versions de C # ne sont, bien sûr, que la pointe proverbiale de l'iceberg. À long terme, .NET Core sera également l'endroit où vous trouverez toutes les «nouveautés» dans le développement de postes de travail. Pour citer Olia Gavrysh (gestionnaire de programme .NET), de retour en novembre 2019 «Nous nous engageons à prendre en charge .NET Framework pour les années à venir, mais il ne recevra pas de nouvelles fonctionnalités, celles-ci être ajouté uniquement à .NET Core (et éventuellement à .NET 5). » Plus précisément, cela signifie que le .NET Framework n'ira pas au-delà de la version 4.8 et ne recevra que les mises à jour «Windows essentielles» (Windows et sécurité).

Certaines de ces nouvelles «nouveautés» sont WinUI (qui I 'ai écrit ailleurs ), qui offre une meilleure expérience aux développeurs (rechargement à chaud pour que vous n'ayez pas à arrêter le débogage pour apporter des modifications à l'interface utilisateur) et un tas de nouveaux contrôles, dont beaucoup sont très conviviaux. Si vous créez des applications WPF, vous pouvez (grâce aux îles XAML) commencer à incorporer ces nouveaux contrôles dans vos applications existantes… à condition que vous soyez passé à .NET 5.

Vous obtiendrez également plus de fonctionnalités dans vos Windows Forms contrôles dans .NET 5, aussi. ListView a une nouvelle API qui vous donne accès à des améliorations significatives concernant la création de groupes; la boîte de dialogue des tâches est beaucoup améliorée; Les boîtes de dialogue de fichiers peuvent mieux gérer leur état (c'est-à-dire se souvenir du dernier dossier que l'utilisateur a regardé pour la dernière fois, par exemple). La prise en charge de l'accessibilité dans les contrôles Windows Forms est également améliorée (et vous n'avez rien à faire non plus pour bénéficier de ces avantages).

Migration

C'est si vous voulez recommencer. Si vous souhaitez déplacer vos applications existantes vers .NET Core / .NET 5, il existe, comme vous pouvez vous y attendre, des problèmes de migration. Les deux grands changements sont la nouvelle structure des fichiers de projet et les nouvelles API.

Entre autres différences, les fichiers de projet sont différents dans le monde .NET Core / .NET 5 car vos références de package NuGet sont déplacées du fichier packages.config vers votre fichier de projet. Et, bien que vous puissiez continuer à utiliser au moins certaines API .NET Framework dans vos applications de bureau .NET Core / .NET 5, vous devriez vraiment utiliser les API cible .NET Core / .NET Standard / .NET Standard (qui sait? Un jour, vous pourrez peut-être déployer sur autre chose que Windows). Il est certainement possible que certaines des API avec lesquelles vous interagissez actuellement ne soient plus présentes et que vous deviez trouver des solutions de remplacement (bien qu'il ne s'agisse généralement que de nouvelles versions de vos API existantes).

La bonne nouvelle est que il existe des outils qui géreront la conversion pour vous ou (à tout le moins) identifieront vos problèmes existants. Vous pouvez, par exemple, cliquer avec le bouton droit sur votre fichier packages.config et sélectionner une option de menu pour déplacer vos paramètres NuGet dans votre fichier de configuration (un nettoyage manuel sera ensuite nécessaire). Au moment où j'écris ceci, il y a un document de migration pour .NET Core 3 que vous pouvez utiliser comme guide (le document .NET 5 est toujours «en construction»).

Nous vivons dans un monde agile avec des outils et des technologies en constante évolution. Il est logique qu'une nouvelle plate-forme offre de réels avantages pour démarrer de nouveaux projets sur cette plate-forme (surtout lorsque le nouvel environnement ressemble tellement à l'ancien). Et, pour la même raison que vous devriez envisager de démarrer de nouveaux projets sur les nouvelles plates-formes, il est également logique de déplacer les applications existantes qui voient beaucoup de désabonnement vers les nouvelles plates-formes. Lorsqu'il existe des avantages en termes de performances et d'accessibilité pour le coût de la migration, il est logique de déplacer des applications même stables. Ce que vous ne pouvez pas faire, c'est ignorer ces nouvelles plates-formes.