Проблема в том, что при перестройке точно такого же кода создается другая сборка по сравнению с результатом предыдущей сборки.Как вычислить хэш сборки, чтобы этот хэш мог использоваться, чтобы определить, изменился ли код в сборке?
Зачем мне это нужно? У меня есть шаблон T4, который генерирует определенный исходный код из данной контрактной сборки. Этот исходный код проверяется в VCS, даже если он сгенерирован. Это связано с тем, что контрактная сборка изменяется относительно редко. Однако, когда это происходит, я хотел бы завершить сборку, если вышеупомянутый шаблон T4 не переоценивается.
Мой план посадить хэш-код сборки контракта в сгенерированном исходном файле, например:
// 1B-D0-06-48-02-C2-C5-C5-48-37-AA-61-66-6B-6D-01
Там бы MSBuild задача, которая выполняется, когда проект, содержащий шаблон построен. Эта задача собирается вычислить хэш харда контракта и сравнить его с тем, который испечен в сгенерированный исходный код. Неравенство означает, что контрактная сборка изменилась, и нам нужно повторно запустить шаблон.
Хранение монтажной версии не помогает - во время разработки оно не меняется.
Другим решением было бы оценить шаблон во время выполнения во временный файл и скопировать его по сгенерированному исходному файлу, если он отличается - не требуется хэш.
Однако я хочу привлечь внимание разработчика к тому, что контракты изменились. На этом этапе я хочу, чтобы разработчик переоценил шаблон вручную. Но только тогда, когда это необходимо.
Я думаю, что я мог бы написать сложный код, который отражает сборку контракта, чтобы создать какое-то каноническое представление его типов. Возьмем хэш этого канонического представления. Однако это не тривиально, и я хотел бы видеть, можно ли его избежать.
Правильный способ сделать это, чтобы дать вашей сборки сильное имя, которое включает в себя криптографической подписи. Эта функция встроена в .NET. Например, https://stackoverflow.com/questions/1436879/what-is-strong-naming-and-how-do-strong-name-a-binary. Если вам нужен другой подход, ваш вопрос слишком широк, так как есть много разных способов сделать это. –
Вы можете проверить, в чем разница, вызванная перекомпиляцией. Скорее всего, это только время компиляции, упоминаемое где-то в метаданных сборки. – max630
@PeterDuniho - подписание не является проблемой. Каким будет следующий шаг? – mark