Подтвердите, что двоичные файлы сайта ASP.NET не меняются после добавления комментариев в исходный код. - PullRequest
1 голос
/ 02 октября 2009

Член моей проектной команды должен добавить комментарии к исходному коду во многие свои проекты ASP.NET, чтобы обеспечить лучшую документацию. Некоторые члены команды проекта рекомендуют проводить тщательное регрессионное тестирование, если мы добавляем какие-либо комментарии к исходному коду, поскольку существует небольшая вероятность того, что часть исходного кода может быть непреднамеренно закомментирована и привести к изменению поведения программы. Затем нам также потребуется провести приложение через процедуру управления изменениями и повторно развернуть его на нашем производственном сервере.

Мне кажется, что мы должны иметь возможность добавлять комментарии исходного кода, перекомпилировать исходный код и использовать что-то вроде хеша md5 (или sha1) (используя что-то вроде fciv ) для сравнения библиотеки DLL до и после, чтобы подтвердить, что комментарии исходного кода не повлияли на скомпилированную версию. Тестируя эту концепцию с помощью простого консольного приложения, я вижу, что проблема заключается в том, что хэш двоичных файлов изменится, если увеличится версия DLL. Если бы я мог удалить манифест из двоичных файлов, возможно, я мог бы тогда провести сравнение двоичных файлов между яблоками и яблоками.

В качестве дополнительной проблемы эти приложения ASP.NET используют модель компиляции веб-сайта ASP.NET, в которой код динамически компилируется (предположительно в папку% SystemRoot% \ Microsoft.NET \ Framework \ version \ Temporary ASP.NET Files). при первом посещении сайта, а не модели веб-приложения, где весь код проекта скомпилирован в одну сборку в папке bin.

Есть идеи?

Ответы [ 2 ]

3 голосов
/ 02 октября 2009

хеширование сборок не работает, даже если версия сделана постоянной, после каждой компиляции меняется уникальный guid, встроенный в сборку, каждый раз создается новый хеш. Можно ли изменить приложение так, чтобы оно было предварительно скомпилировано?

Существует инструмент под названием bitdiffer , который будет сравнивать сборки и сообщать о любых различиях. В рамках вашего интеграционного тестирования вы можете запустить инструмент для новой сборки и сравнить его со сборкой в ​​производстве. это обеспечит выпуск только сборок с изменениями кода.

Существует также инструмент под названием ndepends , который имеет API для сравнения сборок. Это очень круто!

1 голос
/ 09 октября 2009

Ответ Рохана Уэста (спасибо, Рохан!) Привел меня к комментариям bitdiffer , которые предоставили следующее решение:

  • Перед добавлением комментариев к коду заново создайте файлы кода из IL с помощью Reflector и Reflector.FileDisassembler . Это создаст каталог файлов исходного кода, который содержит основной исходный код только без комментариев.
  • Добавить код комментария.
  • Создайте второй каталог сгенерированных файлов исходного кода, используя Reflector и Reflector.FileDisassembler надстройка.
  • Используйте разностный инструмент, такой как WinMerge , чтобы сравнить до и после сгенерированных каталогов исходного кода и подтвердить, что изменения комментария исходного кода не изменили основной код.
...