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

Question

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

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

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

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

AutoDesk есть некоторые данные, опубликованные на этом:

• Unexpected installer launches
• Windows Installer displayed unexpectedly

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

Answer 1

Что касается комментария Питера Купера-младшего к 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 Installer: How can I determine what causes repeated Windows Installer self-repair?. Это длинная статья, потому что существует так много разных способов самовосстановления. Общий знаменатель состоит в том, что различные установщики в вашей системе борются за общий параметр, который они продолжают обновлять со своими значениями при каждом запуске приложения в бесконечном цикле.

Answer 2

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

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

• How to Enable Windows Installer Logging

Далее запустите инсталлятор, и пусть AutoCad установки запуска.

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

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

• Wilogutl.exe

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

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