Langage C#
  1. Langage C#
  3. Pourquoi une DLL différente est-elle produite après une nouvelle génération, sans modification du code?
Intereting Posts
Envoi et réception d’une image sur des sockets avec C # Utilisation de Crystal Reports dans Visual Studio 2005 (application Windows C # .NET) DataContractJsonSerializer peut-il gérer des références cycliques? LINQ GroupPar temps continu append par programme un lien hypertexte à listitem Sérialisation et désérialisation de C # Xml lire deux nombres entiers dans une ligne en utilisant C # Comment appeler un JavaScript stocké dans MongoDb à partir de C # Application de bureau à distance C # utilisant RDP. Comment générer le certificate? Quel cadre utiliser pour les services RESTful dans .net supprimer efficacement les éléments xml en double en c # Comment enregistrer des contrôles créés au moment de l’exécution dans Windows Forms Événement arrêté de déplacement de formulaire C # paramètre de proxy de service Web C #: problème d’inheritance avec la liste

Pourquoi une DLL différente est-elle produite après une nouvelle génération, sans modification du code?

Quand je fais un build propre de mon projet C #, la dll produite est différente de celle précédemment construite (que j’ai sauvegardée séparément). Aucune modification de code n’a été faite, il suffit de nettoyer et de reconstruire.

Diff indique que certains octets de la DLL comportent des modifications – quelques-unes vers le début et quelques-unes vers la fin, mais je ne peux pas comprendre ce qu’elles représentent. Quelqu’un sait-il pourquoi cela se produit et comment l’empêcher?

Cela utilise Visual Studio 2005 / WinForms.

Mise à jour: n’utilise pas l’incrémentation automatique de version ni la signature de l’assembly. Si c’est un horodatage, comment empêcher VS de l’écrire?

Mise à jour: Après avoir regardé dans Ildasm / diff, il semble que les éléments suivants soient différents:

  • Deux octets dans l’en-tête PE au début du fichier.
  • Section { guid }
  • Partie cryptique de la table de chaînes de caractères près de la fin (je me demande pourquoi, je n’ai pas changé les chaînes)
  • Parties des informations d’assemblage à la fin du fichier.

Aucune idée de comment éliminer ces problèmes, si possible …

Ma meilleure hypothèse serait que les octets modifiés que vous voyez sont les colonnes de métadonnées utilisées en interne qui sont générées automatiquement au moment de la construction.

Certaines des colonnes Ecma-335 Partition II (Définition de métadonnées de spécification CLI) pouvant changer par construction, même si le code source ne change pas du tout:

  • Module.Mvid: GUID généré par la construction. Toujours change, chaque construction.
  • AssemblyRef.HashValue: Peut changer si vous faites référence à un autre assemblage qui a également été reconstruit depuis l’ancienne version.

Si cela vous dérange vraiment, mon meilleur conseil pour savoir exactement ce qui est en train de changer serait de modifier les tables de métadonnées actuelles. La façon de les obtenir consiste à utiliser la fenêtre ildasm MetaInfo: 

View > MetaInfo > Raw:Header,Schema,Rows // important, otherwise you get very basic info from the next step View > MetaInfo > Show!

Je pense que ce serait le champ TimeDateStamp dans l’en-tête IMAGE_FILE_HEADER des spécifications PE32 .

Peut-être que les numéros de construction ou de révision ont changé.