.NET est mort, vive le .NET

Microsoft a déjà indiqué que .NET Core était l’avenir de .NET, ce qui signifie que si vous n’avez pas démarré, vous devrez commencer à migrer vos applications .NET Framework existantes vers .NET Core. Nous allons examiner plusieurs raisons d’être enthousiasmés par ce changement ainsi que par la manière de prendre une longueur d’avance sur le mouvement.

Dans un monde en constante évolution des outils, des frameworks et des tendances pour les développeurs, Microsoft a une expérience étonnante dans la prise en charge de l'écosystème .NET et de l'ensemble de la gamme de produits qui l'accompagne. C’est pourquoi le chemin qu’ils ont décidé de suivre avec .NET est surprenant et un peu bien accueilli. Si vous ne l'avez pas encore entendu, .NET 4.8 sera la dernière version du .NET Framework. La prochaine version après .NET Core 3.0 sera .NET 5.0, ce qui signifie que .NET Core assumera le rôle de .NET. L'un des principaux objectifs de .NET Core a toujours été d'unifier le framework en un seul runtime se comportant de la même manière sur toutes les plateformes.

Avec cette annonce, Microsoft va faire deux grandes étapes, l’une prévue et l’autre non prévue. L'étape planifiée consiste à faire en sorte que .NET Core devienne le successeur de l'héritage .NET. L'autre étape, qui sera un peu plus agitée, est le manque de compatibilité ascendante à 100% entre .NET 5 et .NET 4.8. (Au moment de la rédaction de cet article, Microsoft s’est engagé à se rapprocher le plus possible de la parité des API dans .NET 5.0.)

Nous passerons en revue certains des avantages de cette annonce et de la façon de se préparer à ce changement si votre Codebase fonctionne toujours avec .NET Framework 4.8.

Avantages

L'avantage principal de cette annonce est que .NET Core est l'avenir et qu'il reste à rester, ainsi que certaines améliorations de performances.

L'avenir de .NET est open source et illimité. Tandis que .NET s'étend à d'autres plates-formes via Xamarin et Mono, .NET Core représente une approche unifiée de leur diffusion multiplate-forme. Parallèlement à l’unité multiplate-forme, Microsoft pousse également fortement vers une source ouverte pour la plupart de son code. En utilisant une source ouverte .NET, il a modifié les coûts de licence et d’hébergement associés au choix de .NET et ouvert le champ de jeu aux startups et aux développeurs qui ne se passionnent pas pour les langages «de démarrage».
Une autre mention notable est que Microsoft a eu l’occasion rare de réécrire son langage avec tous les avantages du recul et de l’utilisation pratique du monde réel. Ils n'ont certainement pas gaspillé cette opportunité non plus; ils ont apporté des améliorations notables à .NET Core dont vous pourrez tirer parti au fur et à mesure de votre migration.

Plus remarquable, ils ont introduit Span et Memoryqui sont des allocations de mémoire contiguës qui vivre dans la pile et permettre des opérations plus rapides que les tableaux existants. Le concept est assez simple, mais le diable est dans les détails. Ils sont disponibles pour tout le monde, mais sachez que Microsoft a réécrit certaines de ses API internes pour tirer parti des améliorations de performances, de sorte que vous n’aurez pas à apprendre tous les secrets pour en tirer le meilleur parti. [19659009] Attention aux non-débutants

Avant de commencer la préparation de la migration, il existe des non-initiés que, si vous tombez dans ces catégories, vous devrez peut-être repenser vos solutions actuelles ou creuser un peu dans le .NET Framework for the. Durée de vie de votre projet.

Pour le moment, il n'est pas prévu de les implémenter dans .NET Core.

Non-Starters

• AppDomains
• Remoting
• Code Access Security (CAS)
• Security Transparency (Silverlight)
• System.EnterpriseServices

Étapes pour vous préparer à la migration

J'ai déjà donné quelques raisons de s'émerveiller pour l'avenir de .NET et de mettre en garde de savoir si cette migration s'applique correctement à votre besoins, et maintenant nous devons faire un peu de cha Nous nous en tenons à nos bases de code existantes afin de nous préparer pour la prochaine version.

Microsoft a bien construit un ensemble d’outils facilitant la migration.

Étape 1. Définissez votre projet pour cibler .NET Framework 4.7.2

La première étape peut sembler un recul, mais vous voudrez définir votre projet pour cibler .NET Framework 4.7.2. Microsoft recommande d'utiliser la version 4.7.2 car cela vous donne la disponibilité des dernières alternatives d'API pour les cas où .NET Standard ne prend pas en charge les API existantes.

Vous remarquerez que j'ai jeté par hasard .NET Standard sans trop entrer dans les détails. détail. .NET Standard est un ensemble formel d'API destinées à être disponibles sur chaque implémentation .NET, ce qui vous permettra de migrer de manière transparente vers .NET Core à partir de .NET Standard.

Étape 2. Exécutez Votre logiciel. Code via .NET Portability Analyzer

Après vous être assuré que votre code cible .NET Framework 4.7.2, il est temps d'exécuter votre code via .NET Portability Analyzer (ApiPort) pour déterminer la quantité de travail nécessaire. serait nécessaire de porter votre base de code .NET Framework sur .NET Core, .NET Standard, ASP.NET Core, NET Core + Platform Extensions ou
Extensions .NET Standard + Platform. Cet outil est polyvalent car vous pouvez l'utiliser pour analyser votre base de code avec plusieurs options différentes. Il vous permet de spécifier les versions et d'obtenir des recommandations très détaillées.

Si vous utilisez C #, vous pouvez utiliser API Analyzer pour analyser votre code. Bien que cet outil soit utile, il n'est pas spécifique au portage de votre base de code vers .NET Core. Il entre certainement dans la catégorie plus générale d'outils qui permet de rechercher du code obsolète, mais il peut également résoudre certains problèmes de portabilité.

3. Mettez en œuvre votre plan de portage

À ce stade, vous avez une bonne idée de l'étendue des travaux requis pour déplacer votre base de code vers .NET Core ou au moins un chemin potentiel à suivre une fois que vos problèmes de compatibilité sont résolus.
Lorsque vous commencez à porter, vous pouvez utiliser deux techniques pour progresser. La première consiste à copier votre code dans un projet .NET Core, à choisir une version de .NET Standard que vous souhaitez cibler et à référencer vos références ApiPort sur les modifications à apporter, ainsi qu'à extraire les packages NuGet nécessaires. La deuxième option serait de le modifier sur place. La meilleure approche est vraiment basée sur votre code et sur ce qui fonctionne pour vous.

Étape 4. Test

Si vous parvenez à transférer votre code, la prochaine étape consistera à exécuter vos tests unitaires sur la base de code migrée pour: assurez-vous qu'ils travaillent. Il n'y a que trois bibliothèques de test d'unité qui s'exécutent sur .NET Core: MSTest, xUnit et NUnit.

Conclusion

J'espère que l'avenir de .NET vous enthousiasme autant que moi et que vous avez le sentiment qu'il existe une voie à suivre pour votre base de code vers .NET 5.0. Happy Coding!

En savoir plus

Si Microsoft se dirige dans cette direction, l’ensemble de l’écosystème évolue également (notre propre interface utilisateur Telerik pour WinForms / WPF / Reporting prend déjà en charge .NET Core, par exemple). Consultez ce contenu connexe pour en savoir plus sur ce qui s'en vient:

Note de la rédaction: Ce message a été publié à l'origine sur notre blog de Telerik . Découvrez les dernières nouvelles sur les outils de développement .NET et JavaScript.