Как установить флажок на “непроверенный” из msiexec командной строки?
У меня есть msi (созданный с WIX), которому связали флажок с пользовательским свойством (назовите его MY_PROPERTY). Я хотел бы выполнить этот msi из командной строки, указывая 0 (неконтролируемый) или 1 (проверенный) на это свойство. Мой сценарий определит соответствующее значение (на основе среды) и введет то значение в msiexec командную строку. Моя командная строка выглядит примерно так:
msiexec /i my_installer.msi MY_PROPERTY=$value
Где $value равняется 1 или 0, в зависимости от среды. Проблема состоит в том, что независимо от того, что оценивает, я предоставляю для MY_PROPERTY в командной строке, флажок всегда проверяется (и свойство будет всегда устанавливаться на 1). Единственный способ сделать флажок неконтролируемым не состоит в том, чтобы указать свойство (оставьте это неопределенным). Нужно отметить, что это поведение происходит независимо от того, показывает ли UI (добавляющий "/тихий" к вышеупомянутой командной строке, не изменяет это поведение).
Это сообщение MSDN, кажется, указывает, что это - известная "ошибка" в установщике Windows (или более точно, независимо от того, что авторская система записала msi). Постсборка msi взлом предложена как решение. Я задаюсь вопросом, встретился ли кто-либо с этой проблемой и придумал лучшее обходное решение/решение.Спасибо!
Обновление
Я вижу три решения этой проблемы:
- От @Damien имейте сценарий обертки не, передают свойство msiexec, когда его значение 0. Это делает сценарий более сложным и вероятно предотвратило бы меня от способности переопределить значение флажка, это принимает значение по умолчанию к "проверенному".
- От @Michael Urman добавьте пользовательское действие, которое очищает свойство, если его значение является нулем. Это делает msi более сложное, и я должен был бы добавить такое пользовательское действие для каждого флажка в UI.
- Другая идея состоит в том, чтобы просто запретить использование флажков в наших msi установщиках и поля радио использования или выпадает для "истинных/ложных" вопросов вместо этого. В то время как это ограничивает опции UI для наших установщиков, это позволило бы сценариям обертки оставаться простыми, и не требует, чтобы пользовательские действия "взломали" свойства.
Я в настоящее время склоняюсь к опции 3, хотя опция 1 является, вероятно, лучшим ответом на мой исходный вопрос. Какие-либо мысли?
2 ответа
Вот как это "должно" работать - в основном, свойство не существует, пока пользователь не установит флажок, тогда оно "установлено" (существует). Поэтому, если вы хотите выполнить пользовательское действие, когда флажок установлен, вы проверяете существование свойства как условие для запуска пользовательского действия, вместо того, чтобы проверять значение, на которое установлен пользовательский реквизит.
Я думаю, что лучший способ сделать это из командной строки - это то, что вы уже упомянули: если вы хотите, чтобы флажок был выбран, укажите пользовательское свойство в командной строке, в противном случае не указывайте, и флажок не будет выбран.
Как вы обнаружили, флажки истинны (отмечены), когда свойство определено (не пусто), и ложно (не отмечено), когда свойство не определено (пусто). Похоже, вам нужно преобразовать строку среды 1 или 0 в флажок true / false, где 1 или 0 передаются в командной строке. Попробуйте использовать настраиваемое действие set-property, которое устанавливает для вашего свойства значение {} (пусто) с условием, когда свойство уже имеет значение «0» . Запланируйте его как можно раньше в последовательностях Install UI и Install Execute.
Позднее обновление: Что касается необходимости использования нескольких настраиваемых действий для обработки нескольких флажков, у вас есть выбор.Вы можете либо создать несколько действий с набором свойств (преимущество: легко определить, что они делают; стоимость: многие из них), либо вы можете создать одно настраиваемое действие на основе кода, которое проходит по таблице Checkbox для списка свойств, которые нужно преобразовать из 0 в пустое (преимущество: одно действие; стоимость: плохо документированный, настраиваемый код). Второстепенным преимуществом последнего подхода является то, что вы можете обрабатывать необычные настройки Value , например, флажок, который должен установить свойство на 0 , когда он установлен.