Migrer vos applications vers .NET 5 avec l’assistant de migration (partie 1)

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 :

image

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).

image

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 :

image

Windows Terminal : modifier le shell par défaut

A chaque fois que j’ouvre Windows Terminal, cela ouvre PowerShell pour Windows, ce qui ne correspond pas à mes habitudes d’utilisation (PowerShell Core ou Bash Linux/WSL Linux).

POur se faire, allez dans Paramètres :

image

Cela ouvre le fichier de configuration de Windows Terminal dans Code (ou Blocnote en fonction de votre configuration d’ouverture par défaut des fichiers) :

image

La ligne importante est le defaultProfile qui détermine le profile par défaut qui s’ouvre lorsque vous lancez Windows Terminal.

Si vous regardez un peu plus bas, vous trouverez la liste des profils dans la sections profiles/list.

image

Copiez le GUID du profile qui vous intéresse par défaut et copier le dans la valeur de defaultProfile.

Et tada, la fois d’après vous ouvrirez votre shell préféré au lancement de Windows Terminal.

image