.NET Core 3 pour Windows Desktop

En septembre, nous avons publié la prise en charge de .NET Core pour la création d'applications de bureau Windows, y compris WPF et Windows Forms. Depuis lors, nous avons été ravis de voir autant de développeurs partager leurs histoires de migration d'applications de bureau (et de bibliothèques de contrôles) vers .NET Core. Nous entendons constamment des histoires de développeurs de bureaux Windows .NET propulsant leur entreprise avec WPF et Windows Forms, en particulier dans les scénarios où le bureau brille, notamment:

  • Formulaires à interface utilisateur dense sur applications de données (FOD)
  • Interface utilisateur réactive à faible latence
  • Applications qui doivent s'exécuter hors ligne / déconnectées
  • Applications avec dépendances sur les pilotes de périphériques personnalisés

Ce n'est que le début du développement d'applications Windows sur .NET Core. Lisez la suite pour en savoir plus sur les avantages de .NET Core pour la création d'applications Windows.



Pourquoi le bureau Windows sur .NET Core?


.NET Core (et à l'avenir .NET 5 qui sera construit au-dessus de .NET Core) sera l'avenir de .NET. Nous nous engageons à prendre en charge le .NET Framework pour les années à venir, mais il ne recevra pas de nouvelles fonctionnalités, celles-ci ne seront ajoutées qu'à .NET Core (et éventuellement .NET 5). Pour améliorer les piles de bureaux Windows et permettre aux développeurs de bureaux .NET de bénéficier de toutes les mises à jour du futur, nous avons apporté Windows Forms et WPF à .NET Core. Elles resteront toujours des technologies Windows uniquement car il existe des dépendances étroitement couplé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.

Tout d'abord, toutes les améliorations d'exécution et les fonctionnalités du langage seront ajoutées uniquement à .NET Core et à l'avenir à .NET 5. Un bon exemple ici est C # 8 qui est devenu disponible dans .NET Core 3.0. En outre, les versions .NET Core de Windows Forms et WPF feront partie de la plate-forme .NET 5. Ainsi, en portant votre application sur .NET Core aujourd'hui, vous les préparez pour .NET 5.

De plus, .NET Core apporte une flexibilité de déploiement pour vos applications avec de nouvelles options qui ne sont pas disponibles dans .NET Framework, telles que:

  • Déploiement côte à côte. Vous pouvez désormais disposer de plusieurs versions de .NET Core sur la même machine et choisir la version que chacune de vos applications doit cibler.
  • Déploiement autonome. Vous pouvez déployer la plate-forme .NET Core avec vos applications et devenir complètement indépendant de l'environnement de vos utilisateurs finaux - votre application a tout ce dont elle a besoin pour fonctionner sur n'importe quelle machine Windows.
  • Tailles d'application plus petites. Dans .NET Core 3, nous avons introduit une nouvelle fonctionnalité appelée l'éditeur de liens (également parfois appelé trimmer), qui analysera votre code et n'inclura dans votre déploiement autonome que les assemblys de .NET Core nécessaires à votre application. De cette façon, toutes les pièces de la plate-forme qui ne sont pas utilisées pour votre boîtier seront supprimées.
  • Fichiers .exe uniques. Vous pouvez regrouper votre application et la plateforme .NET Core dans un seul fichier .exe.
  • Amélioration des performances d'exécution. .NET Core propose de nombreuses optimisations de performances par rapport à .NET Framework. Lorsque vous pensez à l'historique de .NET Core, conçu initialement pour les charges de travail Web et de serveur, il aide à comprendre si votre application peut voir des avantages notables des optimisations d'exécution. Plus précisément, les applications de bureau avec de fortes dépendances sur les E / S de fichiers, la mise en réseau et les opérations de base de données verront probablement des améliorations des performances pour ces scénarios . Certains domaines dans lesquels vous ne remarquerez peut-être pas beaucoup de changements concernent les performances de rendu de l'interface utilisateur ou les performances de démarrage de l'application.

En définissant les propriétés <PublishSingleFile> , <RuntimeIdentifier> et <PublishTrimmed> dans le profil de publication, vous pourrez déployer une application autonome découpée en tant que fichier .exe unique, comme illustré dans l'exemple ci-dessous.

 <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishSingleFile>true</PublishSingleFile> <RuntimeIdentifier>win-x64</RuntimeIdentifier> <PublishTrimmed>true</PublishTrimmed> </PropertyGroup> 

Différences entre le bureau .NET Framework et le bureau .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 nos efforts était de fournir une parité fonctionnelle entre ces plates-formes dans le domaine du bureau et d'améliorer l'expérience .NET Core à l'avenir. Les applications WPF sont entièrement prises en charge sur .NET Core et prêtes à être utilisées, tandis que nous travaillons sur des mises à jour et des améliorations mineures. Pour Windows Forms, la partie d'exécution est entièrement portée sur .NET Core et l'équipe travaille sur Windows Forms Designer. Nous prévoyons de le préparer d'ici le quatrième trimestre 2020 et pour l'instant, vous pouvez consulter la version Aperçu du concepteur dans Visual Studio 16.4 Preview 3 ou version ultérieure. N'oubliez pas de cocher la case dans Outils-> Options-> Aperçu des fonctionnalités-> Utiliser l'aperçu du concepteur Windows Forms pour les applications .NET Core et redémarrez Visual Studio. Veuillez garder à l'esprit que l'expérience est limitée pour le moment car les travaux y sont en cours.

Changements de rupture


Il y a quelques changements de rupture entre .NET Framework et .NET Core mais la plupart du code lié aux zones Windows Forms et WPF a été porté sur Core tel quel. Si vous utilisiez des composants tels que WCF Client, Code Access Security, App Domains, Interop et Remoting, vous devrez refactoriser votre code si vous souhaitez passer à .NET Core.

Une autre chose à garder à l'esprit - les chemins de sortie par défaut sur .NET Core sont différents de sur .NET Framework, donc si vous avez des hypothèses dans votre code sur la structure des fichiers / dossiers de l'application en cours d'exécution, cela échouera probablement au moment de l'exécution.

En outre, il y a des changements dans la façon dont vous configurez les fonctionnalités .NET. .NET Core au lieu du fichier machine.config utilise le fichier <something>.runtimeconfig.json fourni avec une application et a le même usage général et des informations similaires. Certaines configurations telles que system.diagnostics , system.net ou system.servicemodel ne sont pas prises en charge, donc un fichier de configuration d'application ne pourra pas se charger s'il contient l'une de ces sections. Cette modification affecte le système, le suivi des System.Diagnostics et les scénarios client WCF qui étaient généralement configurés à l'aide de la configuration XML précédemment. Dans .NET Core, vous devrez plutôt les configurer en code. Pour modifier les comportements sans recompilation, envisagez de configurer le suivi et les types WCF à l'aide de valeurs chargées à partir d'une source Microsoft.Extensions.Configuration ou à partir de appSettings .

Vous pouvez trouver plus d'informations sur les différences entre .NET Core et .NET Framework dans la documentation .

Pour commencer


Découvrez ces courts didacticiels vidéo:


Portage de .NET Framework vers .NET Core


Tout d'abord, exécutez l' analyseur de portabilité et, si nécessaire, mettez à jour votre code pour obtenir une compatibilité à 100% avec .NET Core. Voici des instructions sur l'utilisation de l'analyseur de portabilité . Nous vous recommandons d'utiliser un contrôle de code source ou de sauvegarder votre code avant d'apporter des modifications à votre application au cas où le refactoring ne se passerait pas comme vous le souhaitez, et vous décidez de revenir à votre état initial.

Lorsque votre application est entièrement compatible avec .NET Core, vous êtes prêt à la porter. Comme point de départ, vous pouvez essayer un outil que nous avons créé pour vous aider à automatiser la conversion de vos projets .NET Framework en .NET Core - essayez de convertir .

Il est important de se rappeler que cet outil n'est qu'un point de départ dans votre parcours vers .NET Core. Ce n'est pas non plus un produit Microsoft pris en charge. Bien qu'il puisse vous aider avec certains des aspects mécaniques de la migration, il ne gérera pas tous les scénarios ou types de projet. Si votre solution contient des projets que l'outil rejette ou ne parvient pas à convertir, vous devrez effectuer le portage à la main. Pas de soucis, nous avons plein de tutoriels sur la façon de le faire (à la fin de cette section).

L'outil de conversion tentera de migrer vos fichiers de projet de style ancien vers le nouveau style SDK et de recibler les projets applicables vers .NET Core. Pour vos bibliothèques, nous vous laissons le soin de passer un appel concernant la plateforme: météo que vous souhaitez cibler .NET Core ou .NET Standard. Vous pouvez le spécifier dans votre fichier de projet en mettant à jour la valeur de <TargetFramework> . Les bibliothèques sans dépendances spécifiques à .NET Core comme WPF ou Windows Forms peuvent bénéficier du ciblage de .NET Standard:

 <TargetFramework>netstandard2.1</TargetFramework> 

afin qu'ils puissent être utilisés par les appelants ciblant de nombreuses plates-formes .NET différentes. D'un autre côté, si une bibliothèque utilise une fonctionnalité qui nécessite .NET Core (comme les API d'interface utilisateur de bureau Windows), la bibliothèque peut cibler .NET Core:

 <TargetFramework>netcoreapp3.0</TargetFramework> 

try-convert est un outil global que vous pouvez installer sur votre machine, vous pouvez ensuite appeler depuis CLI:

 C:\> try-convert -p <path to your project> 

ou

 C:\> try-convert -w <path to your solution> 

Comme mentionné précédemment, si l'outil try-convert n'a pas fonctionné pour vous, voici des informations sur la façon de porter votre application à la main.

Les vidéos


La documentation

Source: https://habr.com/ru/post/fr475064/


All Articles