#wix #windows-installer #custom-action
#wix #windows-установщик #пользовательское действие
Вопрос:
Мы создали установщик WIX для нашего приложения. Проблема, с которой мы сталкиваемся, заключается в следующем: Мы определили два разных пользовательских действия (скажем, ActionForInstall и ActionForUninstall), которые мы хотим выполнить в следующем случае: ActionForInstall : должен выполняться во время установки, обновления продукта, maintenancemode (как для восстановления, так и для модификации) ActionForUninstall : должен выполняться только для удаления.
Но мы не можем установить правильное условие. Вы можете обратиться к коду :
<Custom Action=ActionForInstall After='InstallFinalize' >
(NOT Installed) OR (Installed AND ((MaintenanceMode = "Modify") OR (MaintenanceMode = "Repair")) AND (NOT (MaintenanceMode = "Remove"))) OR ((UPGRADINGPRODUCTCODE) AND NOT(REMOVE ~= "ALL"))
</Custom>
<Custom Action=ActionForUninstall Before='InstallFinalize'>
Installed AND NOT UPGRADINGPRODUCTCODE
</Custom>
Пожалуйста, сообщите нам, что мы сделали неправильно. Приведенный выше код вызывает InstallFinalize даже для удаления.
Комментарии:
1. Полезная шпаргалка: flexerasoftware.com/webdocuments/PDF / … . Мне нравится отключать пользовательские действия для запуска исправлений MSI, добавляя NOT PATCH в существующий список условий, а также NOT UPGRADINGPRODUCTCODE, чтобы отключить их и для крупных обновлений.
Ответ №1:
Вы можете попробовать выполнить эти условия:
ActionForInstall:
REMOVE <> "ALL"
ActionForUninstall
REMOVE = "ALL"
Комментарии:
1. В зависимости от того, где запланировано пользовательское действие и как выполняется удаление, условие REMOVE =»ALL» может завершиться ошибкой. Например, при выполнении a / x для удаления свойство REMOVE устанавливается сразу. Но при выполнении операции обслуживания и выборе Удаления свойство REMOVE не устанавливается до тех пор, пока не будет произведена оценка. Просто кое-что, о чем следует знать. Я по-прежнему утверждаю, что лучше создавать условия на основе состояний компонентов.
2. @кристофер, ты прав.. но у нас плотный график, и у нас нет эксперта по wix.. для понимания и реализации того, что вы говорите, может потребоваться больше усилий.. Итак, мы используем решение, предоставленное @Cosmin
3. Смотрите мой комментарий, добавленный к вопросу выше относительно основных обновлений и установки исправлений. Эти типы установки используют ту же последовательность установки, что и основная установка, обслуживание и удаление. Часто бывает полезно настроить ваши пользовательские действия так, чтобы они не выполнялись во время этих типов установки.
Ответ №2:
Обычно условия, использующие свойства уровня продукта, такие как Not Installed и REMOVE =»ALL», не соответствуют вашим ожиданиям. Обычно лучше использовать состояния действия компонента, такие как
$COMPONENTNAME=3 <— компонент устанавливается локально
$COMPONENTNAME=2 <— компонент был ранее установлен и теперь удаляется
Обычно это будет охватывать все ваши сценарии установки, удаления, обслуживания, ремонта, обновления.
Вы можете выполнить аналогичные действия для функций, используя оператор «amp;», но обычно лучше использовать компоненты «$», поскольку компоненты являются физическими и могут быть связаны с одной или несколькими функциями, которые являются только логическими.
И если вы действительно хотите перейти на следующий уровень, ваши пользовательские действия могут (должны) управляться данными с использованием соединения внешнего ключа с таблицей компонентов. В этом сценарии ваше пользовательское действие всегда запускается, а затем запрашивает таблицы и оценивает состояния действия компонента, чтобы решить, какие операции необходимо запланировать.