Кто-нибудь знает способ сравнения двух сборок .NET, чтобы определить, были ли они собраны из "одинаковых" исходных файлов?
Я знаю, что есть несколько разностных утилит, таких как плагин для Reflector, но я не заинтересован в просмотре различий в графическом интерфейсе, я просто хочу автоматизированный способ сравнить набор двоичных файлов, чтобы увидеть, были ли они построен из тех же (или эквивалентных) исходных файлов. Я понимаю, что несколько разных исходных файлов могут создавать один и тот же IL, и понимаю, что процесс будет чувствителен только к различиям в IL, а не к исходному.
Основным препятствием для простого сравнения потоков байтов для двух сборок является то, что .NET включает в себя поле под названием «MVID» (идентификатор версии модуля) сборки. Похоже, что для каждой компиляции это значение имеет разные значения, поэтому если вы создадите один и тот же код дважды, сборка будет отличаться.
Смежный вопрос: кто-нибудь знает, как заставить MVID быть одинаковым для каждой компиляции? Это избавило бы нас от необходимости иметь процесс сравнения, который нечувствителен к различиям в значении MVID. Было бы предпочтительнее использовать согласованный MVID, поскольку это означает, что можно использовать стандартные контрольные суммы.
Основанием для этого является то, что сторонняя компания несет ответственность за независимую проверку и подписание наших выпусков до того, как нам разрешат выпустить в производство. Это включает в себя просмотр исходного кода. Они хотят независимо подтвердить, что предоставляемый им исходный код соответствует двоичным файлам, которые мы ранее создали, протестировали и в настоящее время планируем развернуть. Мы ищем процесс, который позволит им независимо собрать систему из источника, который мы им поставляем, и сравнить контрольные суммы с контрольными суммами для двоичных файлов, которые мы тестировали.
КСТАТИ. Обратите внимание, что мы используем непрерывную интеграцию, автоматические сборки, контроль исходного кода и т. Д. Проблема не связана с отсутствием внутреннего контроля над тем, какие исходные файлы вошли в данную сборку. Проблема заключается в том, что третья сторона несет ответственность за проверку того, что источник, который мы им предоставляем, производит те же двоичные файлы, которые мы протестировали и планируем использовать в Production. Они не должны доверять ни одной из наших внутренних систем или элементов управления, включая сервер сборки или систему контроля исходного кода. Все, что их волнует, - это получить исходный код, связанный со сборкой, выполнить сборку самостоятельно и убедиться, что выходные данные соответствуют тому, что мы говорим о развертывании.
Скорость выполнения решения сравнения не особенно важна.
спасибо