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

Question

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

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

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

Спасибо

Answer 1

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

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