Сравнение VB6.exes

Question

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

Очевидно, что код .net легко сравнить, потому что мы можем разобрать. Я не верю, что это возможно в vb6 exes из-за способа компиляции.

Есть ли у кого-нибудь идеи о том, как я могу проверить исходный код и скомпилированный исполняемый файл совпадает с файлом, который у меня есть в Live.

Спасибо

Answer 1

Visual Basic имеет (имеет) два способа компиляции: один для интерпретатора (называемого P-кодом), который приведет к меньшим двоичным файлам, и второй, который генерирует «обычный» файл Windows .exe (называемый native), который был введен, потому что он должен был быть быстрее, чем p-код; хотя размер скомпилированного файла увеличился с этой опцией. Если ваша компиляция использовала p-код, теоретически возможно восстановить исходные коды.

В любом случае это довольно сложно сделать, но есть инструменты, которые утверждают, что они могут частично это делать, и я знаю, что (никогда не пробовал, но есть пробная версия), это VB-декомпилятор http://www.vb -decompiler.org /

Answer 2

Иметь надежный компьютер, который может проверять различные библиотеки и исполняемые вами файлы и автоматически их компилировать. Храните их в доступном только для чтения месте. Затем выполните бинарное сравнение между развернутым сайтом и вашим сайтом сравнения.

Однако я не уверен в логике разборки выполненных блоков. Моя компания и большинство других известных мне мест используют комбинацию сборочного компьютера и модульного тестирования. В нашей компании исполняемый нами EXE-файл представляет собой очень тонкую оболочку над множеством библиотек. Например, нажатие кнопки будет передано в UI Active X DLL, которая выполняет фактическую обработку. После сборки мы запускаем специальный EXE-файл, который выполняет наш список модульных тестов. Если они все прошли, мы знаем, что наши библиотеки, в которых 90% нашего кода, хороши. Что касается самого EXE-файла, то у нас есть ручная процедура, которая занимает около двух часов, а потом все хорошо. В редких случаях случаются ошибки в EXE.

Answer 3

Если у вас есть весь скомпилированный код, вы можете сравнить CRC этого кода с тем, что развернуто в поле. Но если у вас нет исходного скомпилированного кода, в зависимости от того, как вы его скомпилировали (если вы использовали P-код, а не Native Code, вы можете разобрать, но дизассемблирование не будет похоже на исходный код). Я сомневаюсь, что вы бы отправили PDB вместе с exe-файлами, но если бы вы это сделали, вы наверняка могли бы использовать их для сравнения с исходным кодом в вашем хранилище.

Answer 4

Моя старая компания купила копию этого VB-декомпилятора и, как отмечалось ранее, VB5 / 6 генерирует дополнительный код P-Code, этот инструмент действительно генерировал некоторый код, а если не код сборки, который можно было бы «прочитать».

Answer 5

Это не поможет вам с уже развернутыми элементами, но если вы увеличивали номер редакции на каждой компиляции (есть настройка проекта, чтобы сделать это для вас автоматически), то вы могли бы легко сравнить номера версий.

Answer 6

К сожалению, это почти невозможно. Помните, что код VB6, скомпилированный на разных компьютерах, будет иметь разные размеры exe и требования к развертыванию.

Вот почему у старых VB'еров была выделенная машина для компиляции их кода.