Comparez deux versions d'un assembly .NET avec Glass.NET

Vous avez la v1.2.0 d’une DLL et quelqu’un vient de vous passer la v1.3.0. C’est peut-être une dépendance que votre gestionnaire de paquets veut monter, un correctif qu’un éditeur vous a envoyé par e-mail, ou une mise à jour NuGet avec un changelog qui dit « corrections de bugs et améliorations ». Avant de lui faire confiance dans votre build, vous voulez la réponse honnête à une seule question : qu’est-ce qui a vraiment changé ?

Pas ce que prétendent les notes de version. Le vrai diff — types ajoutés et retirés, un corps de méthode réécrit en silence, une signature publique qui s’est déplacée, un appel réseau qui n’était pas là la version d’avant. Et vous le voulez sans le code source (vous ne l’avez pas) et sans exécuter aucune des deux builds (vous ne leur faites pas encore confiance).

C’est un travail de décompilation-et-comparaison, et Glass.NET est fait pour ça. Il est gratuit, et strictement statique — il lit les métadonnées et l’IL et reconstruit le C#, et n’exécute jamais l’assembly qu’il inspecte. Vous pouvez donc comparer en toute sécurité une mise à jour dont vous n’êtes pas sûr : rien dans l’une ou l’autre DLL ne s’exécute. Glass propose une comparaison d’assemblys côte à côte avec un diff ligne à ligne, qui place les deux versions l’une à côté de l’autre et vous montre le delta directement, méthode par méthode.

Pourquoi « lire le changelog » ne suffit pas

Un changelog est une affirmation, pas une preuve. Le binaire livré est la source de vérité de ce qui s’exécute, et il s’écarte du récit par toutes les voies habituelles :

• Le binaire n’est pas le dépôt. Un .nupkg est un artefact compilé tiré d’un flux. À moins d’être une build vérifiablement reproductible, la DLL — pas le tag GitHub — est ce qui s’exécute dans votre processus.
• Les montées de patch cachent de vrais changements. Une version de « correction de bugs » peut ajouter un nouvel appel sortant, changer la façon dont une valeur est validée ou modifier une valeur par défaut. Le versionnage sémantique est une convention, pas une garantie.
• Les ruptures de compatibilité passent en silence. Une méthode publique qui a changé de signature sans prévenir ou qui a disparu cassera ses appelants à l’exécution, même quand le numéro de version dit « montée mineure sûre ».

Lire le delta vous-même est une assurance bon marché, et c’est la même discipline que inspecter un paquet NuGet avant de lui faire confiance — sauf que vous faisiez déjà confiance à l’ancienne version, et n’avez donc qu’à auditer ce qui a bougé.

Chargez les deux versions

Mettez les deux DLL sur disque. Pour une dépendance NuGet, elles sont dans le cache global des paquets — %USERPROFILE%\.nuget\packages\<id>\<version>\lib\<tfm>\ sous Windows, ~/.nuget/packages/... ailleurs — un dossier par version, de sorte que vous pouvez prendre la 1.2.0 et la 1.3.0 côte à côte. Pour une livraison d’éditeur ou votre propre sortie, pointez simplement vers les deux fichiers.

Ouvrez le premier assembly dans Glass.NET (glissez-le sur la fenêtre, ou Fichier ▸ Ouvrir un assembly), puis ouvrez le second. Chacun s’affiche sous forme d’arbre espaces de noms ▸ types ▸ membres, avec du C# lisible reconstruit à la demande — sans PDB, sans Source Link, sans build spéciale.

Lancez la comparaison d’assemblys

Démarrez la comparaison d’assemblys de Glass.NET et choisissez les deux versions comme ancien et nouveau côté. Glass décompile les deux et affiche un diff ligne à ligne du C# reconstruit, aligné pour que vous lisiez la différence directement, au lieu de passer d’une fenêtre à l’autre en vous fiant à votre mémoire. C’est le cœur du flux de travail : vous examinez le delta, vous ne relisez pas toute la bibliothèque.

Parcourez-le avec des questions précises.

1. Quels types et membres sont apparus ou ont disparu ?

Commencez au niveau structurel, avant tout corps de méthode. La comparaison fait ressortir les types et membres nouveaux dans la v1.3.0, absents de celle-ci, ou modifiés. Demandez-vous ce que chacun signifie :

• Un nouveau type — surtout un qui touche aux E/S, à la sérialisation ou au contrôle de processus — est la première chose à comprendre. Un utilitaire de journalisation est banal ; un nouveau *Client ou *Uploader dans une bibliothèque qui n’avait aucune raison de parler au réseau mérite un regard appuyé.
• Un type ou membre retiré est un signal de compatibilité. Si votre code le référençait, la montée vous casse — mieux vaut l’apprendre ici que par une MissingMethodException à l’exécution.
• Un champ ajouté ou retiré sur un type que vous sérialisez peut changer en silence les formats sur disque ou sur le réseau.

2. La surface d’API publique a-t-elle changé ?

Restreignez-vous à la surface publique — le contrat dont dépend tout ce qui est en aval. Dépliez les types et membres publics des deux côtés et laissez la comparaison montrer ce qui a été ajouté, retiré ou re-signé :

// v1.2.0
public Result Process(string input)

// v1.3.0
public Result Process(string input, CancellationToken token = default)

Un paramètre optionnel ajouté ainsi est généralement compatible au niveau source mais pas au niveau binaire — les appelants doivent recompiler, et un plugin chargé contre l’ancienne signature plantera. Une méthode publique retirée, un type de retour modifié ou un paramètre qui a perdu sa valeur par défaut est une rupture plus dure. L’intérêt de comparer spécifiquement la surface publique est que c’est là qu’une montée de version « mineure » fait les dégâts sur lesquels elle est la moins honnête.

3. Qu’est-ce qui a changé à l’intérieur d’un corps de méthode ?

Pour une méthode présente dans les deux versions, le diff ligne à ligne montre exactement comment son C# reconstruit a changé. C’est là que vous attrapez la réécriture silencieuse — ce qu’aucun changelog ne mentionne :

• Une vérification de validation retirée ou assouplie.
• Une constante, une limite ou une valeur par défaut codée en dur qui a bougé.
• Une nouvelle branche qui appelle quelque chose — un fichier, une clé de registre, une URL.

La prise la plus précieuse ici est un nouvel appel réseau ou un lancement de processus que l’ancienne version n’avait pas. Si la v1.3.0 d’un utilitaire de formatage de dates construit soudain un HttpClient et fait un POST vers un point de terminaison codé en dur, le diff met ces lignes exactes devant vous. C’est la même chasse aux signaux d’alerte que couvre analyser un assembly .NET suspect — le diff la réduit simplement à ce qui est nouveau.

4. Lisez l’IL là où le C# est ambigu

Le C# décompilé est une reconstruction, et deux builds réellement différentes peuvent parfois produire du C# qui paraît identique, ou ne différer que d’une manière que la vue C# arrondit — une résolution de surcharge changée, un glissement entre == et object.Equals, une machine à états générée par le compilateur qui s’est réorganisée. Quand le diff C# d’une méthode paraît suspectement vide ou suspectement bruyant et que vous avez besoin de certitude, basculez sur la vue IL de Glass.NET et comparez l’IL directement. L’IL est ce qui s’exécute réellement, c’est donc la vérité de terrain ; lire l’IL est l’arbitre quand le C# est ambigu. Pour la plupart des méthodes, le diff C# suffit largement — recourez à l’IL pour la poignée où cela compte.

Utilisez le rapport d’exposition comme filtre rapide

Glass.NET produit aussi un rapport d’exposition qui résume à quel point un assembly est lisible. Passez-le sur les deux versions comme signal de tri rapide : si la v1.3.0 rapporte soudain bien moins lisible que la v1.2.0, une dépendance jusque-là en clair a peut-être commencé à livrer du code obfusqué ou virtualisé — ce qui, dans une bibliothèque de style open source ordinaire, est déjà une raison de s’arrêter et de demander pourquoi. (Si vous êtes de l’autre côté — à protéger votre propre build — c’est à cela que sert l’obfuscateur frère Nebula.NET, et la virtualisation de code est une fonction Pro ; vous iriez alors vérifier le résultat dans Glass.)

Connaissez les limites

Comparer deux versions vous dit précisément ce qui a changé dans les octets que vous avez — cela ne vous dit pas si un changement est sûr, seulement ce qu’il est ; ce jugement reste le vôtre. La lecture statique ne fera pas ressortir un comportement qui n’apparaît qu’à l’exécution avec des entrées précises, et du code fortement obfusqué peut ne pas se reconstruire proprement d’un côté comme de l’autre (là encore, un signal en soi). Et vous comparez deux builds précises : figez vos dépendances et re-comparez à chaque montée, pour que le delta reste toujours assez petit pour être réellement lu.

C’est tout l’intérêt. Au lieu de ré-auditer une bibliothèque entière à chaque montée, vous n’examinez que ce qui a bougé — nouvelles API, membres retirés, corps réécrits, un nouvel appel réseau — dans un outil gratuit et purement statique qui n’exécute jamais une ligne de l’une ou l’autre build. Téléchargez Glass.NET, chargez les deux versions et lisez le diff avant de faire confiance à la nouvelle.