Savoir de quoi est faite votre application .NET Framework avant d'y toucher.
Legacy Lens lit toute la solution sur votre propre machine et rend un rapport mesuré : ce qu'il y a, ce qui risque de casser, ce qui bloque le passage au .NET moderne, et dans quel ordre s'y prendre.
Le problème
Une application que personne n'ose toucher.
Elle tourne sur .NET Framework. Elle fait tourner l'entreprise. Ceux qui l'ont écrite sont partis. Personne ne peut dire ce que demanderait un passage au .NET moderne, ni par où commencer, sans des semaines de lecture.
Alors elle reste où elle est, et chaque année elle coûte un peu plus à maintenir.
Ce qu'il livre
Un document, pas un tableau de bord.
- La carteProjets, dépendances, tailles, frameworks cibles, et les projets qu'aucun test ne référence.
- Les fichiers à risqueClassés selon leur structure et leur fréquence de changement, avec les raisons à côté de chacun.
- Ce qui bloqueLes paquets sans avenir, les API disparues, et ce que le code en utilise réellement.
- L'ordre des travauxCe qui bloque tout le reste, ce qu'un outil fait seul, ce qui demande une décision. Un ordre de dépendances, pas un planning.
- Un filet de sécuritéDes tests de caractérisation qui enregistrent ce que fait le code aujourd'hui, compilés et exécutés avant que quiconque les voie.
- Les conversions mécaniquespackages.config, format de projet SDK, versions de paquets, configuration : chacune livrée en diff, que personne n'a appliqué.
Pourquoi s'y fier
Rien n'y est généré.
- Rien ne quitte votre machine.L'analyse tourne sur votre poste ou votre serveur. Aucun code source n'est envoyé à un service tiers.
- Chaque chiffre est mesuré.À partir des fichiers de projet, du code source et de l'historique git. Aucun modèle de langage n'écrit le rapport : chaque phrase est un gabarit rempli d'un chiffre mesuré.
- Ce qui n'a pas été vu est écrit.Le rapport se termine par ce qu'il n'a pas pu mesurer : que rien n'a été compilé, que la couverture de tests repose sur une convention de nommage, combien de paquets ne sont pas classés.
- Rien n'est appliqué sans une personne.Les conversions sortent sous forme de patchs. Une personne les lit et décide. L'outil ne pousse rien et n'écrit jamais dans votre copie de travail.
La preuve sur du vrai code
Mesuré sur deux bases de code publiques.
Orchard CMS et nopCommerce 3.90, deux applications ASP.NET MVC sur .NET Framework. Aucune n'est à nous, et aucune n'est versionnée dans le dépôt.
- 414 611lignes d'Orchard CMS, 89 projets, évaluées en une dizaine de secondes, sans rien compiler.
- 0 erreuraprès conversion : Orchard (88 projets) et nopCommerce 3.90 (31) compilent, vérifié sur un runner Windows hébergé.
- ~400 / 128tests de caractérisation conservés sur Orchard et sur nopCommerce, chacun compilé et vert.
- 900+tests automatisés dans l'outil lui-même. Le code est public.
Pas encore prouvé : les applications converties ont été compilées, pas exécutées. Savoir si elles démarrent et servent une page est une autre mesure.
Rapport exemple
Le rapport complet sur Orchard CMS.
Produit par l'outil, sans retouche, en anglais. Il s'ouvre sur le paragraphe destiné à qui n'en lira qu'un :
orchard is 89 projects and 414,611 lines across 6,203 source files. Everything targets v4.8. No test project references 45 of the 78 projects that ship code, covering 75,908 lines.
Qui le fait
Selim Selimi.
Ingénieur .NET senior à Genève. Contributeur d'ILSpy, le décompilateur .NET, et de REA. Legacy Lens est son travail, et le code est public.
Contact
Un échange de 20 minutes, sans engagement.
On regarde ensemble votre situation et si un diagnostic a du sens pour vous.
selimi1203@gmail.com