Même si toutes ne savent pas comment, les sociétés qui développent des logiciels souhaitent suivre le rythme effréné des montées de version, que ce soit des OS, des frameworks ou des bibliothèques. L’objectif est de ne pas être larguer, de pouvoir parfois gagner en performances, résoudre quelques problèmes de sécurité du framework ou encore permettre d’utiliser des technologies plus modernes (HTTP 2, etc) lors de ces passages.
Pour que les équipes de développement, l’objectif sera surtout de suivre les évolutions, d’identifier les breaking change, de refactoriser le code et également de garder la motivation de maintenir, ce qui deviendra quoiqu’on en veuille : ‘une vieille application à maintenir’.
Pour la société, l’objectif sera surtout de minimiser le coût de cette montée de version, qui si elle n’apporte pas de valeur ajoutée pour les utilisateurs (hormis de meilleurs performances et une sécurité parfois renforcé, concernant le framework en lui-même aka cela n’améliorera pas votre code dans ce domaine par magie) permet d’avoir sur le marché des ressources plus à même d’intervenir sur des technologies récentes qu’anciennes.
MAIS … la stratégie est souvent de faire un POC de mise à niveau d’un projet ‘pas trop gros’, et de se dire ‘voici une application A’, on essaye, et si ça ne coûte pas trop cher on fera l’application B, C, etc. Le biais dans lequel l’entreprise risque de tomber est qu’elle pensera que calculer le temps d’upgrade d’un premier projet, sur lequel l’équipe essuie tous les plâtres de la migration, pourra servir de référence de charges/coûts pour les suivantes. C’est du bon sens … mais c’est ce qui se passe tous les jours, dans d’autres domaines dans les sociétés …
En résumé, la migration d’un projet vers .NET Core 5 prendra beaucoup du temps et la décision sera de ne pas migrer les projets amenant une montagne de ‘vieilles applications à maintenir’ à être maintenu par des personnes dont la motivations égalera celle d’un paresseux au repos. Mais tada … Microsoft à créer l’upgrade assistant pour vous afin de vous aider au maximum à pouvoir évaluer la migration et vous assister dans cette tâche, surtout sur les parties simples et fastidieuses d’une migration de code. Mais attention, cet outil est votre assistant et le magicien c’est vous, pas lui !
Installation
L’assistant de migration est un outil dotnet (dotnet tool) qu’il suffit d’installer de cette manière :
Troubleshooting
Erreur “Impossible de charger l’index de service pour la source “/ “Unable to load the service index for source”
Cette erreur arrive lorsque vous avez déclaré un source Nuget dans votre configuration Nuget dont l’outil n’arrive pas à accéder (mauvaise URL, credentials outdated, etc).
Dans ce cas, rien de plus simple vous avez deux options :
1. Utilisez l’argument --ignore-failed-sources
dans la ligne de commande
2. Supprimer la source dans votre fichier de configuration Nuget qui se trouve dans :