Определите, были ли сборки .NET созданы из одного источника

Кто-нибудь знает способ сравнения двух сборок .NET, чтобы определить, были ли они собраны из «одинаковых» исходных файлов?

Я знаю, что есть несколько разностных утилит, таких как плагин для Reflector, но я не заинтересован в просмотре различий в GUI, я просто хочу автоматизированный способ сравнить набор двоичных файлов, чтобы увидеть, были ли они созданы из одинаковые (или эквивалентные) исходные файлы. Я понимаю, что несколько разных исходных файлов могут создавать один и тот же IL, и понимаю, что процесс будет чувствителен только к различиям в IL, а не к исходному источнику.

Основным препятствием для простого сравнения потоков байтов для двух сборок является то, что .NET включает в себя поле под названием «MVID» (идентификатор версии модуля) сборки. Кажется, что это имеет различное значение для каждой компиляции, поэтому, если вы создадите один и тот же код дважды, сборка будет другой.

С этим связан вопрос: кто-нибудь знает, как заставить MVID быть одинаковым для каждой компиляции? Это избавило бы нас от необходимости иметь процесс сравнения, который нечувствителен к различиям в значении MVID. Согласованный MVID будет предпочтительным, поскольку это означает, что можно использовать стандартные контрольные суммы.

Основанием для этого является то, что сторонняя компания несет ответственность за независимую проверку и подписание наших выпусков до того, как нам разрешат выпустить в производство. Это включает в себя просмотр исходного кода. Они хотят независимо подтвердить, что предоставляемый им исходный код соответствует двоичным файлам, которые мы ранее создали, протестировали и в настоящее время планируем развернуть. Мы ищем процесс, который позволит им независимо собрать систему из источника, который мы им поставляем, и сравнить контрольные суммы с контрольными суммами для двоичных файлов, которые мы тестировали.

КСТАТИ. Обратите внимание, что мы используем непрерывную интеграцию, автоматические сборки, контроль исходного кода и т. Д. Проблема не связана с отсутствием внутреннего контроля над тем, какие исходные файлы вошли в данную сборку. Проблема заключается в том, что третья сторона несет ответственность за проверку того, что источник, который мы им предоставляем, производит те же двоичные файлы, которые мы протестировали и планируем использовать в Production. Они не должны доверять ни одной из наших внутренних систем или элементов управления, включая сервер сборки или систему контроля исходного кода. Все, что их волнует, - это получить исходный код, связанный со сборкой, выполнить сборку самостоятельно и убедиться, что выходные данные соответствуют тому, что мы говорим о развертывании.

Скорость выполнения решения сравнения не особенно важна.

Спасибо

Ответы на вопрос(7)

Ваш ответ на вопрос