Comment puis-je savoir si un "assemblage" a vraiment changé?

Question

J'ai créé une simple application "Hello World" dans VS2005. C'est une application de console directe; il ne contient que les lignes suivantes:

Console.WriteLine("Hello World"); 
Console.ReadLine(); 

Quand j'ai essayé de reconstruire la même application de la console sans effectuer des modifications (il suffit d'appuyer sur le bouton reconstruction), je reçois un exécutable subtilement différent. (J'ai généré un hachage SHA-1 à partir du 1er et du 2ème exécutable généré, et c'est différent!)

Pourquoi est-ce différent quand il n'y a pas de changement de code? Qu'est-ce qui a vraiment changé? J'ai utilisé un éditeur hexadécimal pour comparer et n'a vu que quelques octets différents.

Je suppose que ma question ultime est, comment puis-je savoir si un "assemblage" a réellement changé? (Bien sûr, sans regarder les versions de fichier, la taille du fichier, etc.)

EDIT

Jusqu'à présent, nous avons établi que la différence réside dans l'en-tête PE (horodatage et des données de débogage). Avant de réinventer la roue, existe-t-il un outil de "comparaison d'assemblage" qui ignore l'en-tête PE?

Merci, Ian

Answer 1

Les différences seront

• l'horodatage dans l'en-tête PE
• la GUID des données de débogage, si présentes

(et peut-être quelque chose de plus, selon l'autre sortie que vous avez publiée?) Pour les voir, exécutez dumpbin /all /rawdata:none sur les deux assemblys dans une invite de commande VS. Pour faire cela correctement, vous devez écrire un outil de comparaison qui a compris cela et ignoré ces octets - ou pris des copies des exécutables, effacé l'horodatage et le GUID, puis comparé ces versions. Ou, à la rigueur, vous pouvez utiliser quelque chose comme fc /b comme le suggère controlfreak et supposer que s'il y a < 20 octets différents (4 pour l'horodatage, 16 pour le GUID) alors c'est probablement pareil. Vous pouvez très bien utiliser un assembly avec l'horodatage effacé - AFAIK il est seulement utilisé pour mettre en mémoire cache les décalages de symbole exportés dans d'autres DLL si vous le reliez, mais il est probablement plus sûr de le laisser tel quel. Si vous avez réellement besoin d'assemblages binaires identiques, je vous suggère de changer vos processus afin de ne jamais les nettoyer, sauf si vous en avez vraiment besoin.

Answer 2

Sur la ligne de commande fc/b < oldfile> < newfile>

Answer 3

D'un, vous pouvez invite de commande Visual Studio faire une comparaison plus élaborée:

• Vous pouvez comparer l'en-tête de PE en utilisant la sortie de dumpbin:

  dumpbin /HEADERS assembly.dll 
  

• Ou vous pouvez comparer PE en-têtes et le code IL incorporé dans l'ensemble en utilisant ildasm:

  ildasm /ALL /TEXT assembly1.dll > dump1.txt 
  ildasm /ALL /TEXT assembly2.dll > dump2.txt 
  fc dump1.txt dump2.txt   
  

  L'option /ALL va vider les en-têtes DOS et PE, l'en-tête CLR, les métadonnées d'assemblage et l'unité d'assemblage désassemblée. Cependant, il ne contiendra pas de ressources intégrées. Si votre assmembly contient des ressources incorporées, vous pouvez utiliser l'option /OUT. Cela créera un fichier distinct pour chaque ressource incorporée que vous pouvez comparer à l'aide de votre outil de comparaison préféré, par ex. WinMerge:

  ildasm /ALL /TEXT /OUT:folder1\dump.txt folder1\assembly.dll 
  ildasm /ALL /TEXT /OUT:folder2\dump.txt folder2\assembly.dll