Warum wird nach einem sauberen Build ohne Codeänderungen eine andere DLL erzeugt?

Question

Wenn ich eine saubere Build mein C#-Projekt zu tun, ist die erzeugte dll anders als die zuvor gebaut ein (die ich separat gespeichert). Keine Code-Änderungen wurden gemacht, nur sauber und neu erstellen.

Diff zeigt, dass einige Bytes in der DLL Änderungen aufweisen - einige am Anfang und einige am Ende, aber ich kann nicht herausfinden, was diese darstellen. Weiß jemand, warum dies geschieht und wie man es verhindern kann?

Dies geschieht mit Visual Studio 2005 / WinForms.

Aktualisierung: Keine automatische Versionserweiterung oder Signierung der Baugruppe. Wenn es sich um eine Art Zeitstempel handelt, wie kann ich VS daran hindern, ihn zu schreiben?

Aktualisierung: Nach einem Blick in Ildasm/diff scheint es, dass die folgenden Punkte unterschiedlich sind:

• Zwei Bytes im PE-Header am Anfang der Datei.
• <PrivateImplementationDetails>{ Leitfaden } Abschnitt
• Kryptischer Teil der Stringtabelle gegen Ende (warum wohl, ich habe die Strings nicht geändert)
• Teile der Montageinformationen am Ende der Datei.

Ich habe keine Ahnung, wie man sie beseitigen kann, falls das überhaupt möglich ist...

Answer 1

Ich würde vermuten, dass die geänderten Bytes, die Sie sehen, die intern verwendeten Metadaten-Spalten sind, die zur Build-Zeit automatisch generiert werden.

Einige der Spalten von Ecma-335 Partition II (CLI Specification Metadata Definition), die sich pro Build ändern können, auch wenn sich der Quellcode überhaupt nicht ändert:

• Module.Mvid: Eine zur Build-Zeit erzeugte GUID. Ändert sich immer, bei jedem Build.
• AssemblyRef.HashValue: Kann sich ändern, wenn Sie auf eine andere Assembly verweisen, die seit dem alten Build ebenfalls neu erstellt wurde.

Wenn Sie das wirklich stört, wäre mein bester Tipp, um herauszufinden, was sich genau ändert, ein Diff der eigentlichen Metadatentabellen. Diese erhalten Sie über das MetaInfo-Fenster von ildasm:

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

View > MetaInfo > Show!

Answer 2

Ich denke, das wäre das Feld TimeDateStamp in der Kopfzeile IMAGE_FILE_HEADER der Datei PE32 Spezifikationen .

Answer 3

Es könnte sein, dass sich die Build- oder Revisionsnummern geändert haben.