Avec l’évolution rapide des technologies cloud, de nombreuses entreprises cherchent à moderniser leurs plateformes d’intégration. Microsoft BizTalk Server montre aujourd’hui...
16 janvier 2024
Read this post in English
Migration d’une Web API de .NET 6 à .NET 8 : retour d’expérience
La sortie de .NET 8 en novembre 2023 a été un moment attendu par de nombreux développeurs. Ayant à cœur d’être à la pointe de la technologie, j’ai pris la décision de migrer ma Web API depuis .NET 6 vers cette dernière version.
Ce retour d’expérience vise à partager les étapes, les défis rencontrés et les enseignements tirés tout au long de ce processus de migration.
Étape préalable : un environnement Visual Studio à jour
J’ai tout d’abord commencé par mettre à jour mon environnement de développement (Visual Studio 2022) afin de me garantir une compatibilité optimale avec les dernières fonctionnalités .NET 8.
L’avant migration : avoir une application .NET 6 à jour
Avant d’entamer la migration vers .NET 8, une étape préalable cruciale consiste à s’assurer que son application est à jour dans son Framework actuel. Cela consiste à mettre à jour ses dépendances et y être compatible.
Cette précaution sert deux objectifs majeurs :
- Corriger les incompatibilités existantes.
- Limiter les erreurs potentielles post-migration.
Correction des incompatibilités dans un environnement maîtrisé
En examinant et en mettant à jour les paquets NuGet des projets .NET 6, vous vous donnez l’opportunité de remédier aux incompatibilités actuelles, dans un environnement maîtrisé. Cela implique l’identification et la résolution des méthodes dépréciées ou obsolètes,
Réduction des erreurs Post-Migration
En ayant les paquets NuGet à jour dans le projet .NET 6, vous réduisez les risques d’erreurs post-migration. La mise à jour préalable permet de s’affranchir des éventuels conflits ou problèmes de compatibilité qui ne sont pas directement liés au changement de version du Framework. Cela contribue à rendre le processus de migration plus fluide et moins sujet à des erreurs parasites.
En suivant cette étape préalable, vous créez une base stable et préparée pour la migration vers .NET 8, minimisant ainsi les complications potentielles et assurant une transition plus en douceur vers la nouvelle version du Framework.
Utilisation d’un Framework interne
Si vous avez votre propre Framework, il est conseillé d’y effectuer les mêmes vérifications afin qu’il soit également à jour (et cela, même si vos propres paquets seront en majorité compatibles sans modifications).
Il est conseillé de les migrer pour proposer une version en .NET 8 (Version 8.0.0 si vous avez opté pour la même numérotation que Microsoft).
Consultation des changements cassants dans .NET 8
Bien que dans la continuité de .NET 7, le Framework .NET 8 possède tout de même quelques changements cassants.
Pour les identifier, je vous invite à consulter la documentation officielle de compatibilité de .NET 8 fournie par Microsoft : Changements cassants dans .NET 8
En ayant connaissance en amont de ces changements, vous pourrez ainsi anticiper les ajustements nécessaires à la réussite de votre une migration vers .NET 8, et maintenir la stabilité de vos applications en y portant une attention particulière après migration.
Modification du Framework cible
Pour débuter la migration vers .NET 8, j’ai commencé par ajuster le Framework cible dans les propriétés de chacun des projets de ma solution :
Après la modification du Framework cible, il est nécessaire de mettre à jour les paquets NuGet ciblant spécifiquement la version .NET 6, afin de les rendre compatibles avec le nouveau Framework.
C‘est principalement le cas avec les paquets NuGet Microsoft, pour lesquels la version majeure correspond au Framework cible.
| Version | Framework cible |
| V 6.X.X | .NET 6 |
| V 8.X.X | .NET 8 |
Développement et Tests
À la marge de quelques erreurs spécifiques à votre contexte métier, la préparation au préalable et ces ajustements au niveau des projets et des dépendances vous permettront d’avoir très rapidement une version compilable et exécutable en local.
Vous pourrez donc exécuter vos tests unitaires et vérifier le bon fonctionnement via des tests fonctionnels manuels.
En fonction de votre contexte, si vous utilisez un mappeur d’objet relationnel tel qu’Entity Framework, il sera judicieux de tester la création d’une migration et la modification d’une base de données :
Add-Migration -Name Test -Project Projet.Data Update-Database
Erreur lors de l’Intégration Continue avec Azure DevOps
Une fois que notre solution est totalement fonctionnelle en local, il est normal de vouloir remonter ses modifications sur Azure DevOps, via l’Intégration Continue.
Lors de la compilation, le serveur retourne une erreur puisqu’il ne sait actuellement pas compiler le .NET 8. Il est nécessaire de mettre à jour le SDK pour résoudre ce problème :
https://aka.ms/dotnet/download.
##[error] The nuget command failed with exit code(1) and error (C:\Program Files\dotnet\sdk\7.0.403\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(160,5): error NETSDK1045: The current .NET SDK does not support targeting .NET 8.0. Either target .NET 7.0 or lower, or use a version of the .NET SDK that supports .NET 8.0. Download the .NET SDK from https://aka.ms/dotnet/download [D:\a\1\s\XXX\YYY.csproj])
##[error]Packages failed to restore
Gestion des problèmes sur Azure App Service
Le Déploiement Continu s’est, pour ma part, fait sans erreur. Cependant, à l’utilisation, l’application ne fonctionnait pas, l’Azure App Service me retournait la page d’erreur « HTTP Error 500.31 » :
Ce message d’erreur révélait des problèmes liés à la prise en charge de la version de .NET 8 au niveau de l’App Service.
Sur la console de l’App Service, j’ai utilisé la commande « dotnet –info », ce qui m’a permis de connaitre la version installée.
Pour mettre à jour la configuration, je suis allé dans l’onglet « configuration », puis « paramètres généraux », où j’ai pu modifier la version de .NET utilisée :
Modification via Terraform
La modification de la Stack et de la version de .NET utilisée peut également se faire dans une configuration Terraform. Pour une ressource « azurerm_windows_web_app », cela se fait en spécifiant la Stack « dotnet » avec la version souhaitée : « v8.0 ».
site_config {
application_stack {
current_stack = "dotnet"
dotnet_version = "v8.0"
}
}
Vous trouverez les informations nécessaires dans la documentation Terraform : Manages a Windows Web App
Profiter des Nouveautés de .NET 8
Une fois la migration réussie, j’ai pu explorer les nouvelles fonctionnalités de .NET 8. J’ai particulièrement apprécié l’utilisation du constructeur primaire, une fonctionnalité qui améliore la lisibilité du code.
Vous trouverez l’ensemble des nouveautés de .NET 8 dans la documentation officielle de Microsoft : Nouveautés de .NET 8.
Ce qu’il faut retenir : une migration instructive
En conclusion, la migration d’une Web API de .NET 6 à .NET 8 a été une expérience instructive. En combinant la documentation officielle de Microsoft et les ressources de la communauté .NET, j’ai pu naviguer avec succès à travers les étapes de la migration. La gestion proactive des problèmes et la mise à jour régulière ont été les clés du succès de cette transition, ouvrant la porte à un environnement de développement plus moderne et performant.
