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

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

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

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

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

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

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

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

    «Краткая версия» – контрольный список самообслуживания

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

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

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

    Суть проблем с саморемонтом :

    • Большинство проблем с саморемонтом связаны с COM, и для поставщиков и разработчиков есть две общие проблемы: 1) использовать правильно развернутые, общие COM-библиотеки, обычно развернутые с помощью модhive слияния, или 2) использовать без регистрации COM для «защиты» вашего применение от проблем с саморемонтом и совместимостью.
      • Разработчик установки может реализовать исправление модуля слияния, разработчики должны проверить. Объединенные модули стандартизированы, общие библиотеки развертывания для общих файлов.
      • Без регистрации COM работает только с участием разработчиков в моем опыте. Этот параметр особенно важен, если разработчику необходимо использовать определенную версию COM-файла (по какой-либо причине). Подробности в разделе 5.4 ниже.
    • Помимо COM, вы также можете вызвать проблемы с самовосстановлением, установив в своем MSI установочном файле регистратор файлов и MIME-ассоциаций и командных глаголов . Используйте экономно и убедитесь, что ваши ассоциации файлов / 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 или даже в тесте компьютер .
      • Если вы видите проблемы с саморемонтом на одном компьютере, альтернативой может быть восстановление неисправного компьютера . Эффективное устранение, а не «решение» проблемы. Существует относительно высокий риск того, что вы можете снова увидеть проблему . Если вы спросите меня, не перестраивайте, это не решение, но то, что, как мне кажется, делается в реальном мире.
    • Имейте в виду, что установленная AD-версия MSI, которая медленно устанавливается и продолжает прерываться пользователями, может «выглядеть» как проблема самовосстановления для поддержки рабочего стола, но ожидается, что это будет поведение MSI. Разрешить установку установить один раз (можно изменить индикатор выполнения программы установки, чтобы отключить кнопку отмены – что-то вроде msiexec.exe /I "MyApp.msi" /QB-! Для индикатора выполнения только без кнопки отмены и без модального диалога в конце).

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

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

    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 Installer – удалить « рекламируемые ярлыки » (в основном специальный ярлык, который указывает на функцию приложения установщика Windows, а не непосредственно на исполняемый файл или файл). Прочтите связанную статью от Symantec для получения подробной информации о рекламируемых ярлыках.
          • Обратите внимание, что ярлыки могут быть созданы «в любом месте», в том числе в специальных папках, таких как папка «Автозагрузка». Это конкретное местоположение означает, что саморемонт может запускаться сам по себе при запуске системы (без взаимодействия с пользователем).
          • Используйте средство просмотра MSI и откройте системный кэшированный MSI и проверьте его таблицу ярлыков, чтобы найти все ярлыки. Чтобы найти список всех кэшированных пакетов, вы можете попробовать этот ответ: как я могу найти GUID продукта установленной установки MSI? (откройте путь пакета, указанный в «LocalPackage»).
        • Затем вы создаете регулярный ярлык, который указывает непосредственно на исполняемый файл. Это будет «обходить» наиболее распространенный триггер саморемонтирования (объявленный ярлык). В некоторых случаях это устраняет проблему самовосстановления. Это стоит попробовать.
        • Имейте в виду, что даже если это, кажется, работает сразу, самовосстановление может все еще отображаться во время работы внутри приложения (например, когда вы открываете конкретную форму). Вам нужно «пилотировать» это исправление с некоторыми пользователями, которые на самом деле активно используют приложение, чтобы убедиться, что это достаточно подходящее решение для вашей среды.
        • Вы также просто устранили симптом проблемы, конфликт реестра или файла, вызвавший ее, просто был «обойден» или «отключен» – он все еще существует, но это может быть достаточно хорошим, если в приложениях нет проблем во время работы.
        • Фактически существует способ отключить все рекламируемые ярлыки при установке любого пакета MSI. Вы устанавливаете свойство DISABLEADVTSHORTCUTS (одним из способов, описанных в ссылке), а затем все ярлыки создаются как обычные ярлыки, и они не будут запускать саморемонт. Есть как минимум две проблемы :
          • 1) Пакет может быть разработан для использования самовосстановления для установки файлов пользовательского профиля или настроек HKCU. В этом случае эти данные никогда не будут добавляться в систему по мере необходимости, так как саморемонт никогда не будет запущен, и установка будет фактически неполной.
          • 2) Нет гарантии, что самовосстановление не будет продолжаться, поскольку оно может быть вызвано другими рекламируемыми точками входа, такими как COM-вызов, файлы и ассоциации MIME и командные глаголы.
      • 5.3 : Отключить добавление COM (если возможно).

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

        • Вероятно, это решение сложнее, чем виртуализация (которая описана в следующей строке), но я сказал, что это может быть предпочтительным вариантом для некоторых людей.
        • Без учета регистрации COM – это то, что я редко использовал, но он считается жизнеспособным решением: сгенерируйте файлы манифеста для COM без регистрации . Это существенно обходит реестр и активирует частные копии файлов COM, контролируемых файлами манифеста, размещенными рядом с исполняемым файлом (-ами) приложения, – эффективно защищая приложение от вмешательства в реестре COM (теоретически). «Все происходит в одной папке».
        • Ваш собственный отдел упаковки может использовать это для решения проблемных пакетов поставщиков, чтобы «изолировать» их проблемы. Тем не менее, я не уверен, что без регистрации COM будет работать исправно без нескольких дополнительных настроек приложения, внесенных разработчиком исходного решения, но мне не хватает эмпирических данных для его резервного копирования. Если это собственное приложение с доступным исходным кодом, дайте ему пробное rotation (и сообщите нам об этом).
        • Моя основная проблема с этим подходом заключается в том, что он открывает потенциальные дыры в безопасности (частные копии COM-файлов, которые никогда не будут исправлены Microsoft), если вы не убедитесь, что изолированные компоненты обновлены самостоятельно. Обновления, скорее всего, вызовут много работы с манифестным переписыванием (но все же эти старые COM-файлы вообще обновлены?)
        • Обратите внимание, что COM, по меньшей мере, не имеющий регистрации, по крайней мере теоретически, может использоваться для всех конфликтов, связанных с COM, независимо от того, являются ли они исполняемыми файлами VB6, приложениями VC ++, которые используют COM, и т. Д. Я честно не уверен, что он работает правильно (офис) COM addins (dlls) и 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 Installer – ( Небезопасно! ).

        • Я включаю этот «вариант» для полноты и « исторических целей », если хотите. Это никогда не было хорошим вариантом, и теперь он очень опасен в новых версиях Windows.
        • MsiZap.exe – это инструмент Microsoft SDK, предназначенный как средство последнего разработчика для разработчиков для очистки неудачных MSI-установок или удалений, поэтому он никогда не предназначался для широкого использования. Это позволило полностью «грязную регистрацию» любого пакета MSI. MsiZap.exe теперь устарел , не поддерживается и небезопасен для использования. Используйте только на виртуальных сайтах, если это вообще возможно.
        • В тот же день общий « трюк системного администратора » состоял в том, чтобы использовать MsiZap.exe для « zap » всего пакета установщика Windows из системы. Помимо того, что ваша система неистово загрязнена, она также удалила все проблемы с саморемонтом для этого приложения.
        • Убой, оставленный после запуска MsiZap.exe, включает в себя практически все (за исключением фактической регистрации базы данных MSI). Все файлы, все записи в реестре (в том числе COM), SharedDll ref counters (которые действительно испортили вещи при переустановке), сервисы, что-то действительно. Вы никогда не сможете правильно удалить . В большинстве случаев вам не удастся установить обновленные версии одного и того же приложения без побочных эффектов. Многие люди на самом деле больше видят проблемы с саморемонтом, пытаясь установить поверх грязного состояния.
        • Роб Меншинг, создатель 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 interop.
    • Предложение 5.5виртуализация – это общий вариант в наши дни, и его, вероятно, следует попробовать до 5.4, если он доступен в среде. Как говорится, « виртуализировать, серьезно ».
      • Я честно не знаю (нехватка опыта), если виртуализация жизнеспособна для (офисных) аддинов. Обновите, если вы можете подтвердить.
      • Исполняемые файлы могут быть виртуализированы.
    • Предложение 5.6 – « кэширование настроек MSI » – это « взлом », который может работать «достаточно хорошо», когда это делается специалистами по развертыванию .
      • Есть некоторые « побочные эффекты », особенно для удаления, а также для «отказоустойчивости», но они должны быть управляемыми, если все сделано правильно.
      • Это «реальный мир» – ничто не «чисто».
    • И предложение 5.7 – « zapping MSI » – это небезопасный, устаревший «устаревший взлом».
      • Существует несколько побочных эффектов из-за «грязного состояния» системы.
      • Сообщается о суммарном повреждении базы данных MSI после запуска MsiZap.exe.

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

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

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

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

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

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

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

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

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

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

    Давайте будем гением компьютера.