Kennt jemand eine Möglichkeit, zwei .NET-Assemblys zu vergleichen, um festzustellen, ob sie aus "denselben" Quelldateien erstellt wurden?

Ich bin mir bewusst, dass es einige verschiedene Dienstprogramme gibt, z. B. das Plugin für Reflector, aber ich bin nicht daran interessiert, Unterschiede in einer GUI anzuzeigen. Ich möchte nur eine automatisierte Methode zum Vergleichen einer Sammlung von Binärdateien, um festzustellen, ob sie erstellt wurden die gleichen (oder äquivalenten) Quelldateien. Ich verstehe, dass mehrere unterschiedliche Quelldateien dieselbe IL erzeugen können, und erkenne, dass der Prozess nur für Unterschiede in der IL empfänglich ist, nicht für die ursprüngliche Quelle.

Das Haupthindernis beim einfachen Vergleichen der Byteströme für die beiden Assemblys besteht darin, dass .NET ein Feld namens "MVID" (Module Version Identifier) für die Assembly enthält. Dies scheint für jede Kompilierung einen anderen Wert zu haben. Wenn Sie also denselben Code zweimal erstellen, ist die Assembly unterschiedlich.

Eine verwandte Frage lautet: Weiß jemand, wie die MVID für jede Kompilierung gleich sein muss? Dies würde vermeiden, dass wir einen Vergleichsprozess benötigen, der unempfindlich gegenüber Unterschieden im Wert der MVID ist. Eine konsistente MVID wäre vorzuziehen, da dies bedeutet, dass Standardprüfsummen verwendet werden könnten.

Der Hintergrund dahinter ist, dass ein Drittunternehmen dafür verantwortlich ist, unsere Releases unabhängig zu überprüfen und zu unterzeichnen, bevor wir sie für die Produktion freigeben dürfen. Dies beinhaltet die Überprüfung des Quellcodes. Sie möchten unabhängig voneinander bestätigen, dass der von uns bereitgestellte Quellcode mit den zuvor erstellten, getesteten und geplanten Binärdateien übereinstimmt. Wir suchen nach einem Prozess, der es ihnen ermöglicht, das System unabhängig von der Quelle zu erstellen, mit der wir sie beliefern, und die Prüfsummen mit den Prüfsummen der von uns getesteten Binärdateien zu vergleichen.

BTW. Bitte beachten Sie, dass wir kontinuierliche Integration, automatisierte Builds, Quellcodeverwaltung usw. verwenden. Das Problem hängt nicht mit einem internen Mangel an Kontrolle darüber zusammen, welche Quelldateien in einem bestimmten Build abgelegt wurden. Das Problem ist, dass ein Dritter dafür verantwortlich ist, zu überprüfen, ob die Quelle, die wir ihm geben, dieselben Binärdateien erzeugt, die wir getestet haben und die wir für die Produktion planen. Sie sollten keinem unserer internen Systeme oder Kontrollen vertrauen, einschließlich dem Build-Server oder dem Quellcode-Kontrollsystem. Sie kümmern sich nur darum, die Quelle mit dem Build zu verknüpfen, den Build selbst durchzuführen und zu überprüfen, ob die Ausgaben mit den von uns angegebenen Ergebnissen übereinstimmen.

Die Laufzeitgeschwindigkeit der Vergleichslösung ist nicht besonders wichtig.

Vielen Dan