Ответ 1

Конкретный совет по дизайну для вашего файла 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?.. p >

Исправление проблем, связанных с самопроверкой установщика Windows

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

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

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

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

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

2. Определите виновника для самостоятельного ремонта.

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

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

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

4. Обратитесь к поставщику (-ам) (или к вашему собственному отделу упаковки).

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

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

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

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

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

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

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

  • 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 файлов, которые никогда не будут исправлены Microsoft), если вы Убедитесь, что изолированные компоненты обновлены самостоятельно. Обновления, скорее всего, вызовут много работы с манифест-переписыванием (но все же эти старые COM файлы вообще обновлены?)
    • Обратите внимание, что COM без учета, по крайней мере теоретически, может использоваться для всех конфликтов, связанных с COM, будь то исполняемые файлы VB6, приложения VС++, которые используют 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 Installer и проанализировать, возможно ли "исправление". Он может работать, но не ожидайте чудес.
      • Если вы настаиваете на отладке себя, вам нужно овладеть инструментом для открытия кэшированных файлов MSI в системе (, таких как Orca, Installshield, Advanced Installer или аналогичные), и вам нужно "взломать" базу данных - не рекомендуется.

  • 5.7: Установка Windows Installer zapping - (Не безопасно!).

    • Я включаю этот "вариант" для полноты и " исторические цели", если хотите. Это никогда не было хорошим вариантом, и теперь он очень опасен в новых версиях Windows.
    • MsiZap.exe - это инструмент Microsoft SDK, предназначенный как средство последнего времени для разработчиков для очистки неудачных MSI-установок или удалений, поэтому он никогда не предназначался для широкого использования. Это позволило полностью "грязную регистрацию" любого пакета MSI. MsiZap.exe теперь устарел, неподдерживаемый и небезопасно. Используйте только на виртуальных видах обмена, если это вообще возможно.
    • В те дни, когда общий " трюк системного администратора" должен был использовать MsiZap.exe в zap"весь пакет установщика Windows из системы. Помимо того, что ваша система неистово загрязнена, она также удалила все проблемы с самообслуживанием для этого приложения.
    • Убой, оставленный после запуска MsiZap.exe, включает практически все (кроме фактической регистрации базы данных MSI). Все файлы, все записи в реестре (в том числе COM), SharedDll ref counters (которые действительно испортили вещи при переустановке), сервисы, что-то действительно. Вы никогда не сможете правильно удалить. В большинстве случаев вы не сможете установить обновленные версии одного и того же приложения без побочных эффектов. Многие люди на самом деле больше видят проблемы с саморемонтом при попытке установить поверх грязного состояния.
    • Rob Mensching, создатель 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.

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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