Перезагрузка при установке, не перезагружаться при удалении

Question

Перезагрузка при установке, не перезагружаться при удалении

У нас есть установщик, который требует перезагрузки при установке, но он также перезагружается при удалении. Есть ли способ предотвратить перезагрузку при удалении?

Вот что мы имеем на данный момент:

<InstallExecuteSequence>
  <ScheduleReboot After="InstallFinalize"/>
</InstallExecuteSequence>

Спасибо заранее!

1

wix windows-installer wix3 major-upgrade

Источник

user8973844 17 фев '18 в 10:20

1 ответ

Решение

Другие вопросы по тегам wix windows-installer wix3 major-upgrade

user129130 17 фев '18 в 15:02 2018-02-17 15:02 · Accepted Answer · 2018-02-17 15:02

Добавить условие в ScheduleReboot

Вы должны вставить условие для вашего ScheduleReboot запись в соответствии с тем, что описано здесь: https://www.firegiant.com/wix/tutorial/events-and-actions/extra-actions/ (связанная статья может показывать условие, которое является слишком инклюзивным или неограниченным).

ОБНОВЛЕНИЕ: Есть несколько вопросов для рассмотрения:

Нежелательное действие: ScheduleReboot никогда не должен использоваться, за исключением случаев, когда это действительно необходимо. Например, если вы пытаетесь заменить используемые файлы, MSI справится с этим без вызова ScheduleReboot.
Множество режимов установки: без надлежащего условия, ScheduleReboot вызовет приглашение перезагрузки во многих режимах установки: установка, удаление, обновление, восстановление, самостоятельное восстановление, исправление и т. Д. Это нежелательно.
Тихая, мгновенная перезагрузка: если MSI работает в режиме без вывода сообщений и REBOOT=ReallySuppress не указан, действие ScheduleReboot автоматически инициирует мгновенную перезагрузку соответствующего компьютера - что может быть очень неожиданным и очень нежелательным.

Для вашей цели вы можете использовать условие по следующим направлениям:

<InstallExecuteSequence>
    <ScheduleReboot After='InstallFinalize'>NOT Installed AND NOT WIX_UPGRADE_DETECTED</ScheduleReboot>
</InstallExecuteSequence>

Все зависит от того, хотите ли вы запланировать перезагрузку во время крупного обновления или только во время первоначальной, новой установки? Невозможно сказать без дополнительной информации. Более заурядные условия, такие как NOT Installed AND NOT REMOVE~="ALL" может показаться, что он запланировал перезагрузку во время крупного обновления, но не для удаления вручную, не вызванного значительным обновлением (я проверю, когда у меня будет возможность - ОБНОВЛЕНИЕ: проверено, только базовое тестирование).

Обратите внимание, что специальные WIX_UPGRADE_DETECTED Свойство - это специфичная для WiX конструкция, которая может быть установлена только при использовании элемента MajorUpgrade WiX. Вы также можете настроить крупные обновления по старинке в WiX и избежать "удобной функции" элемента MajorUpgrade, которая позволяет упростить настройку основного обновления с меньшим количеством параметров - "авто-магия". Я не проверял, если WIX_UPGRADE_DETECTED все еще настроен с использованием этой конфигурации "старшей школы".

Вы также можете использовать ActionProperty из таблицы обновлений, чтобы определить, что "должно произойти значительное обновление" ( см. этот ответ для примера). Это должно работать даже для установок MSI не-WiX - и как таковая должна быть альтернативой WIX_UPGRADE_DETECTED (Я считаю, что это свойство устанавливается после запуска FindRelatedProducts).

WIX_UPGRADE_DETECTED vs UPGRADINGPRODUCTCODE

Для пакета MSI, удаляемого во время крупного обновления, будет установлено специальное свойство UPGRADINGPRODUCTCODE (которое не будет установлено в MSI, устанавливаемом во время обновления). Это встроенное свойство MSI, а не специфичная для WiX конструкция. Другими словами, во время серьезного обновления, которое представляет собой удаление старой версии и установку новой версии, удаляемый MSI будет иметь свойство UPGRADINGPRODUCTCODE устанавливается, пока устанавливаемый MSI будет иметь свойство WIX_UPGRADE_DETECTED установить (я проверю это в ближайшее время). Он также будет иметь ActionProperty из таблицы обновлений после стандартного действия FindRelatedProducts побежал.

Если это звучит сложно, то я боюсь, что это так. Это ключевая проблема с установщиком Windows ( несмотря на основные корпоративные преимущества технологии) - базовые ключевые операции, такие как обновления, иногда очень сложно понять. Там могут быть некоторые нарушения принципа наименьшего удивления. Есть все хорошее и плохое во всех технологиях - очевидно.

Особые соображения

Обратите внимание, что перезагрузка может быть инициирована независимо от того, подавлено ли действие ScheduleReboot или нет (например, если есть файлы, которые не могут быть заменены - или хуже: пользовательское действие вызывает перезагрузку с помощью кода - что всегда неправильно, перезагрузка должна быть запланировано не принудительно через код).

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

MSI Условия

Условия MSI могут быть очень сложными, чтобы получить право. Неправильно, и ваши действия неожиданно выполняются в неправильном режиме установки - или не запускаются вообще, когда должны. Это намного легче ошибиться, чем вы думаете - даже с опытом. Доказательство в пудинге здесь, в реальных испытаниях. Вот пример сложных условий в качестве примера: Обновление Wix Tools использует старые пользовательские действия (на всякий случай, если это интересно).

Существует множество режимов установки, которые вы должны проверить, когда пытаетесь использовать сложные условия (или любое условие в этом отношении): 1. fresh install, 2. repair, 3. modify, 4. self-repair, 5. patching, 6. uninstall, 7. major upgrade invoked uninstall и т. д. Есть также несколько странных режимов, таких как возобновленная приостановленная установка со свойством RESUME, и свойство AFTERREBOOT, относящееся к действию ForceReboot и т. д. Следует помнить, что они редко тестируются.

Вот две "шпаргалки" для кондиционирования:

У меня не было времени, чтобы пройти все эти условия и проверить их, но последняя таблица выглядит разумно по номинальной стоимости. Однако: я верю REMOVE иногда может быть установлен во время установки (и во время изменения). Очень сложно справиться со всеми изменениями возможностей, поскольку интерфейс командной строки MSI и конфигурация свойств очень гибки. Installed также не установлен для новой версии MSI, устанавливаемой как часть серьезного обновления, но будет установлен для деинсталлируемой версии MSI - очень запутанно.

Шпаргалка Installshield, которую я никогда активно не использовал и не проверял, но я нахожу их предложения для repair по меньшей мере, интересно - есть разные записи в зависимости от того, как вызывается ремонт.

Пожалуйста, не забудьте также проверить самовосстановление - просто удалите основной EXE-файл приложения и запустите самовосстановление, вызвав объявленный ярлык приложения (если есть). Прошло много лет с тех пор, как я проверил, но самовосстановление может запускать действия только между InstallInitialize и InstallFinalize. Вы не хотите планировать перезагрузку во время самостоятельного ремонта.