Что делать при запуске приложения, которое вызывает повторяющееся бесконечное самовосстановление установщика Windows?

Question

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

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

• Повторное самостоятельное восстановление установщика Windows может происходить при каждом запуске приложения на рабочей станции. Как это можно исправить, или как компоненты можно отключить, чтобы это никогда не повторилось?
• Установщик WiX может быть развернут, и вы увидите повторное самостоятельное восстановление установщика Windows при каждой попытке запуска приложения.
• При включении или установке надстройки MS Office вы испытываете непрерывное самовосстановление установщика Windows при запуске одного или нескольких приложений MS Office.
• Когда вы работаете над устаревшими решениями в VB6 или VBA, при запуске основной среды разработки для разработчиков включается самовосстановление для несвязанного продукта.
• При открытии формы в Outlook, Excel или Word или аналогичных приложениях начинается самовосстановление для несвязанного продукта другого поставщика.

---

Ключевые слова: установщик Windows запускается неожиданно. MSI отображается неожиданно. Установщик Windows появляется каждый раз. Открытие приложения запускает установщик Windows. Установщик Windows самовосстанавливающийся. Как происходит самовосстановление пакета. Лучшая практика самовосстановления MSI. Ремонт установщика Windows. Самовосстановления. Отключить установщик Windows. Установщик Windows неоднократно запускается. Ярлык приложения запускает установщик вместо этого. Установщик Windows появляется неожиданно.

Answer 1

Самовосстановление, простое и краткое объяснение: почему установщик MSI переконфигурирует, если я удаляю файл?

---

Советы по конкретному дизайну для вашего файла WiX / MSI

Я продолжаю пытаться писать о повторяющемся самовосстановлении MSI для разработчиков, но в итоге слишком много деталей. Вот моя последняя попытка: конкретные советы по проектированию того, чего не следует делать в вашем файле WiX / MSI.

Ответ ниже предоставляет контрольный список для решения любых сценариев самовосстановления - от любого поставщика или источника, а не только от вашего собственного. Проверьте ответ, связанный выше, для ваших собственных проблем дизайна пакета MSI.

"Короткая версия" - контрольный список самовосстановления

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

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

Системные администраторы должны знать, на что они обращают внимание, и, когда нет доступных исправлений, использовать различные обходные пути для решения проблемы на свободе. Даже конечные пользователи могут сами попробовать несколько простых решений (см. Раздел 5).

Суть проблемы самовосстановления:

• Большинство проблем самовосстановления связаны с COM, и есть два основных исправления для поставщиков и разработчиков: 1) использовать правильно развернутые, совместно используемые библиотеки COM, обычно развертываемые с помощью модулей слияния, или 2) использовать COM без регистрации, чтобы "защитить" свой приложение от вопросов самовосстановления и совместимости.
  • Ваш разработчик установки может реализовать исправление модуля слияния, разработчики должны проверить. Модули слияния - это стандартизированные общие библиотеки развертывания для общих файлов.
  • COM без регистрации работает только с участием разработчиков в моем опыте. Этот параметр особенно актуален, если разработчику необходимо использовать определенную версию COM-файла (по какой-либо причине). Подробности в разделе 5.4 ниже.
• Помимо COM, вы можете также вызвать проблемы с самовосстановлением, если ваш установщик- разработчик зарегистрирует файловые и MIME-ассоциации и командные глаголы в вашей настройке MSI. Используйте экономно, и убедитесь, что ваши файловые /MIME ассоциации являются уникальными.
• Наконец, вы можете вызвать самовосстановление при любом конфликте файлов или реестра между двумя установленными файлами MSI. Они " делят ресурс по ошибке " и будут рассматривать его как свой собственный - сражаясь с ним до тех пор, пока конфликт не будет решен.
• Некоторые проблемы с самовосстановлением связаны не с ошибками в приложении или настройке поставщика, а с внешними факторами в рассматриваемой компьютерной среде, такими как помехи от манипулирования пользователями, скриптами, вирусами, антивирусами или программным обеспечением безопасности. Смотрите раздел 3 для более подробной информации.

Быстрые варианты для решения проблемных приложений

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

Большинство из этих предлагаемых "решений" в разделе 5 на самом деле являются в основном приемами системного администратора, которые не устраняют основную проблему - как указано выше, реальное исправление должно исходить от поставщика. Исключение составляет "5.4: COM без регистрации", которое может помочь разработчикам "защитить" свои приложения от проблем самовосстановления.

Если у вас нет прав администратора на вашем ящике, советуем попробовать "решения" 5.2, 5.3 или 5.1 (для 5.1 обычно требуются права администратора, но это не сложно). Это " быстрые обходные пути ", остальные более вовлечены. Если эти обходные пути не работают, пожалуйста, попросите администратора прочитать другие предложения.

Понимание самовосстановления установщика Windows

Ранее я подробно писал об этой проблеме, но она слишком сосредоточена на понимании проблемы, а не на том, чтобы найти для нее приемлемое решение. Вы можете прочитать полное объяснение проблем самовосстановления здесь: Как я могу определить причины неоднократного самовосстановления установщика Windows?,

Исправление проблем самовосстановления установщика Windows

Чтобы на самом деле исправить повторяющийся и бесконечный самовосстановление, вы можете попробовать приведенные ниже предложения в разделе 5 - в порядке возрастания сложности и сложности. Прежде чем сделать это, вы должны проверить, какова реальная причина проблемы самовосстановления. Это может быть вызвано не файлами MSI, а другими внешними причинами (такими как сценарии или пользователи, удаляющие файлы или файлы антивирусной блокировки).

Если проблема действительно связана с MSI, вы можете попытаться отключить объявленные ярлыки и надстройки COM, использовать COM без регистрации, получить помощь от поставщика приложений, удалить вредоносные приложения, виртуализировать пакеты или полностью взломать кэшированную базу данных MSI и реестр (не рекомендуется, и действительно возможно только с помощью экспертов). Все зависит от вашего сценария. Если виноваты внешние причины, такие как сценарии, вы должны устранить это вмешательство. Смотрите подробности ниже - просто следуйте контрольному списку.

Первые шаги для решения проблемы - определить, что проблема действительно существует на вашей платформе, а затем определить, какие приложения запускают самовосстановление в первую очередь:

1. Убедитесь, что проблема действительно существует в вашей среде.

• Как правило, всегда можно выяснить, что является причиной проблемного самовосстановления, и для решения проблемы можно использовать несколько жизнеспособных обходных путей. Однако не всегда возможно найти хорошее, постоянное исправление (без помощи поставщика - как описано ниже).
  • Соответственно, если вы являетесь системным администратором и пытаетесь найти решение для вашей проблемы самовосстановления, возможно, убедитесь, что проблема видна на нескольких компьютерах, особенно если проблема обнаружена на разработчике, QA или даже на тесте. компьютер.
  • Если вы видите проблемы самовосстановления только на одном компьютере, альтернативой может быть восстановление проблемного компьютера. Эффективное устранение, а не "решение" проблемы. Существует относительно высокий риск того, что вы можете снова увидеть проблему. Если вы спросите меня, не перестраивайте, это не решение проблемы, но я думаю, что обычно происходит в реальном мире.
• Имейте в виду, что установка MSI, рекламируемая AD, которая медленная и продолжает прерываться пользователями, может "выглядеть" как проблема самовосстановления для поддержки настольных компьютеров, но это ожидаемое поведение MSI. Позвольте установке завершиться один раз (можно изменить индикатор выполнения программы установки, чтобы отключить кнопку отмены - что-то вроде msiexec.exe /I "MyApp.msi" /QB-! только для индикатора выполнения без кнопки отмены и без модального диалога в конце).

2. Определите виновника (ей) для самовосстановления.

• Одно приложение может вызвать проблему самостоятельно, но, как правило, конфликтуют как минимум два приложения (они по ошибке делят некоторый ресурс).
• Триггер для самовосстановления обычно можно найти в программе просмотра событий в системе, в которой выполнялся самовосстановление. Выполните следующие действия, чтобы открыть средство просмотра событий:
  • Щелкните правой кнопкой мыши "Мой компьютер"
  • Нажмите Управление
  • Нажмите продолжить, если вы получите приглашение UAC
  • Перейдите в раздел "Просмотр событий" и проверьте журналы Windows.
• Определите приложение-нарушитель в журнале событий Windows, заглянув в раздел " Приложение " журнала событий, и вы найдете предупреждения из источника событий " MsiInstaller " с идентификаторами 1001 и 1004.
  • Более подробную информацию о том, как это сделать, вы можете найти в более подробном ответе здесь: Как я могу определить, что вызывает повторное самостоятельное восстановление установщика Windows?, Посмотрите в разделе " Поиск триггера или виновника для самовосстановления ".
  • Вы также можете воспользоваться советом независимого специалиста по развертыванию, эксперта MSI и MVP Стефана Крюгера. У него есть статья о той же проблеме самовосстановления. И он решительно обсуждает реальные записи журнала событий и что они значат. Пожалуйста, прочитайте о фактической процедуре отладки там.

3. Убедитесь, что внешние причины не MSI не вызывают проблему

• Все, что удаляет файлы или параметры реестра, вручную или автоматически, может вызвать самовосстановление MSI. Особенно, если вы возитесь с удалением материала в профиле пользователя или в разделе реестра HKCU.
  • В большинстве случаев такие триггеры приводят к запуску только одного самовосстановления, а затем проблема устраняется (именно так самовосстановление должно работать и помогать пользователям). Разрешите запуск самовосстановления один раз, а затем снова запустите приложение, чтобы проверить, устранена ли проблема. Так и должно быть, и ваше приложение должно теперь правильно запускаться.
  • Особый случай: по иронии судьбы вы можете иногда исправить поврежденное приложение, переименовав его ключ приложения HKCU (в пользовательском разделе реестра), чтобы фактически запустить самовосстановление и установить данные приложения по умолчанию в профиле пользователя - если эти данные были случайно удален (этот тип исправлений обычно не работает на терминальных серверах).
  • Если тот же файл или запись реестра снова будут удалены с помощью автоматических средств и результатов самовосстановления, вы должны устранить или обновить вызывающий их автоматический процесс, и ваша проблема будет решена, и вы сможете прекратить чтение. Если вы вручную удалили файл снова, то вы можете страдать от плохой памяти:-).
  • В общем, сценарии очистки, сценарии входа в систему, очистки приложений или манипулирования чрезмерно активные пользователи могут вызвать этот вид самовосстановления.
• Наконец, вирусы, а также антивирусное программное обеспечение (и другое программное обеспечение безопасности) могут блокировать доступ к файлам и запускать самовосстановление, которое никогда не будет успешным.
  • Для зараженного компьютера просто восстановите компьютер. Это сэкономит вам время в целом.
  • Если у вас есть проблемы с антивирусным программным обеспечением или защитным программным обеспечением, обратитесь к специалистам по безопасности, чтобы решить их. Им может потребоваться связаться с продавцом в некоторых случаях (особенно для ложных срабатываний).
  • Независимо от вируса или антивируса, проверьте файл на http://www.virustotal.com/, чтобы проверить, является ли он вирусом или просто ложным срабатыванием (что может быть еще большей проблемой для самовосстановления).
  • Лично я видел несколько проблем самовосстановления, связанных с антивирусом / программным обеспечением безопасности, но никаких реальных проблем, связанных с вирусами (пока). Я предполагаю, что вирусы обычно заражают системные файлы ядра, а не файлы приложений, и системные файлы ядра не должны развертываться файлами MSI (общие системные файлы могут быть включены в файлы MSI, но не в системные файлы ядра).

4. Свяжитесь с поставщиком (ами) (или вашим собственным отделом упаковки).

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

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

  • Исправление 1: Исправление может быть таким же простым, как если бы поставщик удалил частные, но глобально зарегистрированные COM-файлы с соответствующим общим " модулем слияния ", чтобы правильно установить среду выполнения для всех. Они должны правильно установить COM-файлы в общие папки, где они могут быть зарегистрированы без побочных эффектов. Готов для всех.
  • Исправление 2: Если производитель заявляет, что это невозможно, то он должен иметь возможность обеспечить надлежащую установку COM без регистрации с должным образом изолированными файлами COM, установленными в основной папке приложения. Они также должны позаботиться о развертывании любых обновлений безопасности всякий раз, когда они появятся.

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

• Проблема также может быть вызвана другими проблемами, но очень часто COM является виновником. Иногда очистка их установщика MSI может разрешить другие, более неясные конфликты. Если вы знаете хорошего упаковщика приложений, он должен уметь быстро выявлять конфликты (и предоставлять обратную связь продавцу).
• Обратите внимание, что также возможно, что самовосстановление вызвано ошибочной (внутренней) переупаковкой программного обеспечения поставщика. В этом случае вы можете исправить свои собственные пакеты с помощью обновлений, поставляемых вашим собственным отделом упаковки / развертывания (и они определенно должны быть в состоянии достичь этого в большинстве случаев). На самом деле это очень распространенная проблема.

5. Выберите "обходной путь" или исправьте, чтобы справиться с конфликтной ситуацией.

• Если поставщик (поставщики) не предоставит фиксированный установочный пакет, вам нужно найти "обходной путь", чтобы справиться с ситуацией. Есть несколько вариантов, и некоторые " быстрые обходные пути " должны быть опробованы, прежде чем углубляться в слишком большую сложность. Вот некоторые предложения по решению проблем в порядке возрастания уровней сложности и сложности:

  • 5.1: Просто удалите виновника (-ов).

    • Абсолютно самое простое решение - выяснить, какие приложения запускают самовосстановление, и просто удалить его, если это приемлемое решение для вашей среды (это редко случается).
    • Это может быть приемлемо, если два (или более) приложения находятся в конфликте, и одно из них используется редко или является "необязательным".
    • Вместо этого вы можете запустить проблемное приложение на виртуальной машине (см. Раздел 5.5). Это было бы моим предпочтительным "исправлением" для очень "плохо себя чувствующего" приложения. Все проблемы должны исчезнуть без какой-либо реальной отладки (что является дорогостоящим).
    • Простая деинсталляция - это вариант, который, по крайней мере, стоит рассмотреть - некоторые программы могут быть очень проблемными во многих отношениях, и их просто следует отклонить для использования. Обязательно сообщите продавцу, что программное обеспечение также было отклонено. Возможно, это единственный способ заставить их серьезно относиться к проблеме.

  • 5.2: Удалить объявленные ярлыки.

    • Первый обходной путь для установщика Windows - это удаление " объявленных ярлыков " (по сути, это особый тип ярлыка, который указывает на функцию приложения установщика Windows, а не непосредственно на исполняемый файл или файл). Прочитайте связанную статью от Symantec для получения подробной информации о рекламируемых ярлыках.
      • Обратите внимание, что ярлыки можно создавать "где угодно", в том числе в специальных папках, таких как папка "Автозагрузка". Это конкретное местоположение означает, что самовосстановление может быть инициировано само собой при запуске системы (без взаимодействия с пользователем).
      • Используйте средство просмотра MSI и откройте MSI, кэшированный системой, и просмотрите его таблицу ярлыков, чтобы найти все ярлыки. Чтобы найти список всех кэшированных пакетов, попробуйте следующий ответ: Как я могу найти GUID продукта установленной установки MSI? (откройте путь к пакету, указанный в "LocalPackage").
    • Затем вы воссоздаете обычный ярлык, который указывает непосредственно на соответствующий исполняемый файл. Это позволит "обойти" наиболее распространенный триггер самовосстановления (рекламируемый ярлык). В некоторых случаях это позволяет избежать проблемы самовосстановления. Это стоит попробовать.
    • Имейте в виду, что даже если кажется, что это работает сразу же, самовосстановление все еще может появиться, пока вы работаете внутри приложения (например, когда вы открываете определенную форму). Вам нужно "опробовать" это исправление с некоторыми пользователями, которые на самом деле активно используют приложение, чтобы убедиться, что это достаточно хороший обходной путь для вашей среды.
    • Вы также просто устранили симптом проблемы, конфликт реестра или файла, который вызвал ее, просто "обойден" или "отключен" - она ​​все еще существует, но это может быть достаточно, если приложения не испытывают проблем во время работы.
    • Фактически существует способ отключить все объявленные ярлыки при установке любого пакета MSI. Вы устанавливаете свойство DISABLEADVTSHORTCUTS (одним из способов, описанных в ссылке), и тогда все ярлыки будут создаваться как обычные ярлыки, и они не будут запускать самовосстановление. Есть как минимум две проблемы:
      • 1) Пакет может быть спроектирован так, чтобы использовать самовосстановление для установки файлов userprofile или настроек HKCU. В этом случае эти данные никогда не будут добавлены в систему, как предполагалось, поскольку самовосстановление никогда не будет выполнено, и установка фактически не завершена.
      • 2) Нет гарантии, что самовосстановление все равно не произойдет - поскольку оно может быть вызвано другими объявленными точками входа, такими как вызов COM, сопоставление файлов и MIME и командные глаголы.

  • 5.3: Отключить надстройки COM (если это возможно).

    • Если ваша проблема связана с загрузкой надстройки (для Outlook, Excel, Word или других приложений, таких как AutoCAD или аналогичных), то нет никаких ярлыков для подстройки - надстройка загружается при запуске своего "главного приложения".
    • Самый простой способ - отключить любые надстройки, которые вам не нужны, в диалоговом окне надстроек соответствующего приложения (часто это Outlook, Excel или Word или аналогичные) и посмотреть, устранит ли это проблему. В некоторых случаях вы просто отключаете надстройки COM, которые пользователи никогда не использовали, и проблема была устранена.
    • И, очевидно, также попробуйте отключить надстройки, которые вам действительно нужны, чтобы проверить, может ли проблема быть связана с их загрузкой. Если надстройка является виновником, вы должны продолжить вниз по контрольному списку до следующих предлагаемых решений (следующие пункты).
    • Я должен еще раз повторить, что предпочтительное решение будет исправлено поставщиком (чаще всего это будет связано с тем, чтобы надстройка правильно использовала последние общие общие элементы управления ActiveX/OCX, о которых идет речь - другие надстройки могут все еще вызывать проблему, если они также плохо спроектирован. Вы можете в конечном итоге иметь дело с несколькими поставщиками - обычно обвиняя друг друга).
    • По справедливости для поставщиков, проблема также может быть вызвана неправильной переупаковкой корпоративных приложений - если вы работаете на корпоративной машине. Тогда вы должны разобраться с отделом упаковки для исправления.

  • 5.4: попробуйте COM без регистрации

    • Возможно, это решение является более сложным, чем виртуализация (которая описана в следующем пункте), но я поместил его здесь, поскольку он может быть предпочтительным вариантом для некоторых людей.
    • COM без регистрации - это то, чем я редко пользуюсь, но считается жизнеспособным решением: генерировать файлы манифеста для COM без регистрации. По сути, это обходит реестр и активирует частные копии COM-файлов, управляемых файлом (-ами) манифеста, размещенными рядом с исполняемыми файлами приложения, - эффективно защищая приложение от вмешательства реестра COM (теоретически). "Все происходит в одной папке".
    • Ваш внутренний отдел упаковки может использовать это для решения "сложных пакетов поставщиков", чтобы "изолировать" их проблемы. Тем не менее, я не уверен, что COM без регистрации будет работать должным образом без нескольких дополнительных настроек приложения, внесенных разработчиком оригинального решения, но мне не хватает эмпирических данных для их резервного копирования. Если это собственное приложение с доступным источником, протестируйте его (и дайте нам знать).
    • Моя главная проблема с этим подходом состоит в том, что он открывает потенциальные дыры в безопасности (частные копии COM-файлов, которые никогда не будут исправлены Microsoft), если вы не убедитесь, что изолированные компоненты обновляются самостоятельно. Обновления, скорее всего, также вызовут много работы по переписыванию манифеста (но все равно обновляются ли вообще эти старые COM-файлы?)
    • Обратите внимание, что COM без регистрации, по крайней мере, теоретически, может использоваться для всех связанных с COM конфликтов, будь то исполняемые файлы VB6, приложения VC++, использующие COM и т. Д. Я честно не уверен, что он работает должным образом (офис) COM-надстройки (dll) и формы VBA.
    • Вот то, что кажется одной из лучших статей MSDN о COM без регистрации): https://msdn.microsoft.com/en-us/library/ms973913.aspx (есть даже загружаемый MSI с примерами, который по иронии судьбы, кажется, вызвать ошибку при запуске).
    • Лично я, вероятно, предпочел бы попробовать виртуальный пакет, используя APP-V, а не пытаться использовать COM без регистрации (см. Следующий пункт).
    • Следует повторить, что вместо того, чтобы "экранировать" собственное приложение, правильное исправление поставщика - прекратить развертывание частных копий общих COM-файлов, которые были ошибочно зарегистрированы во всей системе, и начать их установку, как предполагалось, с использованием соответствующего модуля слияния для развертывание.

  • 5.5. Виртуализация (APP-V, виртуальная машина и т. Д.).

    • Помимо удаления или отключения компонентов, простейшим решением является использование виртуализации для "изоляции" конфликтующих приложений. Если вам все еще нужны приложения в вашей основной SOE (стандартной операционной среде), вы можете попробовать использовать пакет виртуального развертывания (APP-V). Это приложение, которое в основном устанавливается по требованию (при запуске) и запускается в "песочнице" или изолировано от других приложений в системе.
    • Вы также можете использовать виртуальную машину через такие системы, как VMWare или Microsoft Virtual PC, для запуска проблемных приложений в их собственной операционной системе. Часто люди имеют права администратора при использовании виртуальных машин, но не имеют своей основной системы SOE (основной рабочей станции). Многие приложения для разработчиков более эффективно использовать с правами администратора, поэтому это решение может быть особенно полезно при работе с командами разработчиков и их требованиями.

  • 5.6: Настройка установщика Windows - (Только для экспертов!).

    • Если проблема очень серьезна для вашего рабочего стола и ни один из перечисленных выше вариантов не работает, вы можете попытаться устранить проблему на уровне установщика Windows. Это может стоить того, чтобы надстройка (или любое другое программное обеспечение) имела решающее значение для обеспечения доступности в основной компьютерной среде компании.
    • По сути, вам нужно удалить поврежденные записи из системного кэшированного MSI и / или реестра (отключить объявленные точки входа, такие как объявленные ярлыки, регистрация COM, ассоциации файлов, ассоциации MIME или командные глаголы и т. Д.).
      • Это очень сложная и не очень хорошая практика, и есть некоторые побочные эффекты (для деинсталляции, отказоустойчивости и т. Д.), Но это единственное "последнее средство", о котором я знаю.
      • В этих случаях вам следует обратиться к специалисту по развертыванию / установщику Windows и попросить их проанализировать возможность "исправления". Это может работать, но не ожидайте чудес.
      • Если вы настаиваете на отладке самостоятельно, вам понадобится инструмент для открытия кэшированных файлов MSI в системе ( например, Orca, Installshield, Advanced Installer или аналогичный), и вам необходимо "взломать" базу данных - не рекомендуется.

  • 5.7: загрузка установщика Windows - (небезопасно!).

    • Я включаю этот "вариант" для полноты и " исторических целей ", если хотите. Это никогда не было хорошим вариантом, и теперь очень небезопасно в новых версиях Windows.
    • MsiZap.exe - это инструмент Microsoft SDK, предназначенный для разработчиков в качестве последнего средства для устранения неудачных установок или деинсталляций MSI, он никогда не предназначался для широкого использования. Это позволило полную "грязную отмену регистрации" любого пакета MSI. MsiZap.exe устарел, не поддерживается и небезопасен в использовании. Используйте только на одноразовых виртуалах, если они вообще есть.
    • В свое время обычным " трюком системного администратора " было использование MsiZap.exe для " удаления " из системы всего пакета установщика Windows. Помимо того, что ваша система оставалась неизлечимо грязной, она также устраняла все проблемы самовосстановления для этого приложения.
    • Мусор, оставшийся после запуска MsiZap.exe, включает в себя практически все (кроме фактической регистрации базы данных MSI). Все файлы, все записи реестра (включая COM), счетчики ссылок SharedDll (которые действительно портят вещи при переустановке), сервисы, что-нибудь действительно. Вы никогда не сможете удалить должным образом. В большинстве случаев вам не удастся установить обновленные версии одного и того же приложения без побочных эффектов. Многие люди на самом деле видят больше проблем с самовосстановлением, когда пытаются установить поверх грязного состояния.
    • Роб Мэншинг, создатель WiX, Orca и всего прочего Windows Installer, имеет пост в блоге об опасностях MsiZap. MSDN описывает еще один плохой побочный эффект: вся информация об обновлении программы удаляется при использовании средства Msizap.exe для удаления программы с компьютера под управлением Windows

6. Резюме и заключение

• Шаг 4 - обращение к поставщику за исправлением - на мой взгляд, единственное " настоящее исправление ".
  • Все остальные предложения направлены на решение проблем, возникающих в результате ошибок поставщиков, а не на долговременное решение.
  • Проблема реального мира заключается в том, что многие поставщики склонны обвинять друг друга, поэтому вам может не повезти. И некоторые поставщики, которые делают это правильно, страдают от ошибок проектирования других.
• Предложения 5.1, 5.2, 5.3 являются несложными " обходными путями ".
  • Должно быть безопасно попробовать для всех.
  • Предложения 5.2 и 5.3 можно попробовать даже без прав администратора.
• Предложение 5.4 - COM без регистрации - довольно сложное, потенциальное "исправление".
  • Вовлечению разработчика может потребоваться найти все зависимые файлы для "изоляции".
  • По моему опыту, это такой проект, который в конечном итоге занимает несколько дней, чтобы попробовать (даже с помощью экспертов) - без реальной гарантии, что он в конечном итоге будет работать.
  • Я слышу противоречивые мнения экспертов, некоторые добились успеха, некоторые говорят, что это не удалось. Люди с доступом к источнику решения, похоже, преуспевают.
  • Лично мне не нравятся потенциальные дыры в безопасности, которые он открывает, и любые новые версии файлов для развертывания могут означать новый раунд повторной авторизации манифеста (я полагаю).
  • Однако рассматриваемые COM-файлы настолько стары, что вряд ли они увидят какие-либо обновления безопасности, сделанные для них в любом случае. Я полагаю, что эти COM-объекты в настоящее время в основном используются для взаимодействия.NET.
• Предложение 5.5 - виртуализация - является распространенным вариантом в наши дни, и, вероятно, его следует попробовать до версии 5.4, если оно доступно в среде. Как говорится, " виртуализируйся серьезно ".
  • Честно говоря, я не знаю (не хватает опыта), является ли виртуализация жизнеспособной для (офисных) надстроек. Пожалуйста, обновите, если вы можете подтвердить.
  • Исполняемые файлы можно определенно виртуализировать.
• Предложение 5.6 - " кэшированная настройка MSI " - это " хак ", который может работать "достаточно хорошо", если все сделано специалистами по развертыванию.
  • Есть некоторые " побочные эффекты ", особенно для удаления, а также для "отказоустойчивости", но они должны быть управляемыми, если все сделано правильно.
  • Это "реальный мир" - ничто не является "чистым".
• И предложение 5.7 - " zapping MSI " - является небезопасным, устаревшим "устаревшим хаком".
  • Есть несколько побочных эффектов из-за "грязного состояния" системы.
  • После запуска MsiZap.exe было зарегистрировано полное повреждение базы данных MSI.

Answer 2

Там должно быть проблема внутри вашего пакета. Чтобы найти проблему.

1. Очистить журнал событий - приложение.

2. Запустите ваше приложение как пользователь с AdminRigths

3. Приложение должно запускаться после самостоятельного ремонта. Вы можете запустить дважды, если самовосстановление не появится, после второго запуска это означает, что существует проблема с компонентом, который хочет создать запись внутри MachinePart, например, HKLM или Programfiles или папку Windows.

4. Откройте свой журнал событий и найдите запись с исходным кодом MSIInstaller.

5. Запись с предупреждением даст вам информацию о том, какие функции и компоненты вызовут самовосстановление.

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

Answer 3

Поскольку это происходит каждый раз, когда вы запускаете свое приложение (и я предполагаю, что вы разрешаете выполнение восстановления до конца), наиболее вероятной причиной является то, что приложение удаляет что-то, что "защищено" установщиком Windows, например запись реестра или файл. Сочетание клавиш запускает механизм восстановления для переустановки отсутствующего элемента, и запись MsiInstaller сообщит вам, что это такое.

В целом, ремонт - это хорошая вещь, потому что он позволяет пользователю восстановить установленный продукт, если он поврежден. Если, по замыслу, существуют ресурсы, которые установлены, но не нуждаются в ремонте, установите для Component Id значение NULL в вашем WiX, потому что это документированный способ предотвратить восстановление определенных файлов, см. Примечания ComponentId здесь:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx