Migration .NET 6 vers 8

Migration .NET 6 vers .NET 8 : Guide complet pour une mise à jour réussie

Durée : 2 heures 

Cycle de vie des version .NET 

Microsoft déploie chaque année une version majeure de son Framework .NET. L’éditeur fournit également des mises à jour et corrections de bugs pendant toute la durée du support. Les versions .NET sont à classer dans 2 catégories :  

• Standard Term Support (STS) – La durée de suivi est de 1,5 ans. À privilégier quand on veut bénéficier des dernières innovations et possibilité du Framework. Cependant cela nécessitera des migrations plus fréquentes. 

• Long Term Support (LTS) – La durée de suivi est de 3 ans. A privilégier pour les applications nécessitant une stabilité à plus long terme. 

.NET 6 est une version LTS qui a atteint la fin de son support en novembre 2024. Il est donc temps de migrer vers la prochaine version LTS disponible : .NET 8 

Prérequis 

• Parlez-en avec vos équipes (Dev, QA …). Toutes les personnes susceptibles de démarrer votre projet devront suivre ces prérequis. 

• Installer SDK .Net 8.0 : https://dotnet.microsoft.com/fr-fr/download/dotnet/8.0 

• Pour l’IDE Rider : il faut à minima la version 2023.3 

• Pour l’IDE Visual Studio : dans Visual Studio Installer, cochez la case « .NET 8.0 Runtime » 

Avant de commencer la migration, finissez tout travail en cours. Je n’ai personnellement pas rencontré de problèmes mais mieux vaut être paré à toute éventualité.
Créez une nouvelle branche
git checkout -b Migration.Net8 

Migration des fichiers csproj 

– <TargetFramework>net6.0</TargetFramework>
+ <TargetFramework>net8.0</TargetFramework> 

Migration des fichiers Dockerfile 

– FROM mcr.microsoft.com/dotnet/sdk:6.0
+ FROM mcr.microsoft.com/dotnet/sdk:8.0 

Migration des packages Nuget 

Avant de commencer cette étape, je vous conseille de faire un commit pour revenir facilement en arrière : 

git commit 

Mettre à jour chaque PackageReference présent dans les fichiers csproj.
Ça peut être long et fastidieux, heureusement un outil tiers simplifie cette tâche pour nous : dotnet-outdated 

1. Installation de dotnet-outdated
   dotnet tool install –global dotnet-outdated-tool 

1. Recherche des packages pouvant être mis à jour 

dotnet outdated 

1. Mise à jour des packages
   dotnet outdated –u 

Test et vérification 

1. Vérifie que la solution build toujours
   dotnet build 

1. Grâce aux tests unitaires, on s’assure que rien n’est cassé
   Pour en apprendre plus sur les tests, je vous invite à lire cet article de Dorra BARTAGUIZ qui couvre bien le sujet.
   dotnet test 

1. Ensuite on peut lancer le projet et vérifier que tout fonctionne (merci les tests end-to-end)
   dotnet run 

1. Vérification CI – Fichiers yml
   En ce qui me concerne il n’y a rien à modifier car pas de mention de la version de .Net 

1. Vérification CD – Azure
   Facultatif – Il s’avère que l’API fonctionne même si .Net 6 est sélectionné
   Je vous conseille d’appliquer quand même cette étape
   Dans mon Application API, dans le menu de gauche : Paramètre > Configuration
   On change « Version .NET » 

On teste et tout est bon ! 

Gestion des changements majeurs 

Si jamais vous avez des erreurs de compilation dans le code, vous pouvez consulter les recommandations Microsoft :
https://learn.microsoft.com/en-us/dotnet/core/compatibility/7.0
https://learn.microsoft.com/en-us/dotnet/core/compatibility/8.0 

Conclusion 

Depuis quelques années, Microsoft privilégie des sorties de versions régulières et facile à migrer. Ainsi pour éviter d’être débordé, il est essentiel de maintenir ses projets à jours au fur et à mesure. Cette approche “baby step” permet de limiter la dette technique et de pérenniser nos développements tout en bénéficiant des nouvelles fonctionnalités, des optimisations de performance et des derniers correctifs de sécurité.  

La sortie de la prochaine version Long Term Support .NET 10, est prévue pour novembre 2025.