Диагностика самовосстановления MSI

Приложение, над которым я работаю, написано в основном в VB6.

Некоторые пользователи сообщают, что когда они запустили мое приложение, другой установщик MSI автоматически запустится и попытается восстановить собственную установку. Часто это относится к AutoCAD, но иногда и к другим программам.

Обычно это происходит каждый раз, когда они запускают приложение.

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

В AutoDesk есть информация, опубликованная по этому вопросу:

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

ОТВЕТЫ

Ответ 1

Ваш установщик работает с ключом каталога, файла или реестра, который знает установщик Windows, является частью установки AutoCad.

Во-первых, я включил бы глобальное ведение журнала Windows Installer.. Это означает, что любая работа установщика Windows, включая установщик AutoCad, записывается во внешний файл журнала (в% temp%).

Затем запустите ваш установщик и включите установщик AutoCad.

Теперь перейдите к% temp%, и вы должны найти файлы MSIXXXX.LOG - один для вашего установщика, один для AutoCad. Откройте их, и вы сможете проложить себе путь через них и определить, какой файл или раздел реестра обнаружен или изменен в приложении AutoCad MSI.

Вы можете найти WiLogUtl.exe полезным для этого:

С какой-либо удачей вы обнаружите, что каталог, файл или ключ реестра, запускающий autorepair, также находится в вашем установщике. Если вам действительно повезло, вы можете определить его как элемент, который вы не должны устанавливать в любом случае - возможно, вы ссылаетесь на системный компонент, который будет присутствовать в любом случае, что-то, защищенное Windows File Protection.

Если нет, вам придется посмотреть что-то вроде RegFree COM, чтобы переместить файлы из общих каталогов в ваш частный каталог и уменьшить конфликты реестра. Кроме того, если вы используете (потребляете) MSM для среды Visual С++ для создания MSI, рассмотрите возможность использования установщика Microsoft EXE или (лучше всего) размещение DLL непосредственно в папке вашей программы, так как я обнаружил, что МСМ могут вызывают такую ​​проблему.

Ответ 2

Что касается комментария Питера Купера-младшего к VB6, вызывающего саморемонт. Пожалуйста, ознакомьтесь с документацией heat.exe для Wix. Вы увидите, что есть специальный переключатель, который поддерживает инструмент, чтобы отключить извлечение определенных значений реестра, которые принадлежат самой среде выполнения VB6 (и, следовательно, не следует смешивать или обновлять любую другую MSI): http://wixtoolset.org/documentation/manual/v3/overview/heat.html

Перейдите в список до переключателя -svb6 и прочитайте описание справа. (Воспроизводится здесь:)

При регистрации COM-компонента, созданного в VB6, он добавляет реестр записи, которые являются частью компонента времени исполнения VB6:

  • CLSID {D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
  • Typelib {EA544A21-C82D-11D1-A3E4-00A0C90AEA82}
  • Typelib {000204EF-0000-0000-C000-000000000046}

[а также] Любые интерфейсы, которые ссылаются на эти библиотеки типов

Записывает ли ваш установщик эти ключи? Если это попытается их исключить - это хорошо сделать, даже если это не является виновником в этом конкретном случае.

Кроме того, существует подробное описание того, что может привести к самовосстановлению установщика Windows: Как определить, что вызывает повторный автозапуск установщика Windows?. Это длинная статья, потому что существует так много разных способов самовосстановления. Общим знаменателем является то, что различные установщики в вашей системе борются с общим параметром, который они продолжают обновлять со своими значениями при каждом запуске приложения в бесконечном цикле.