Это не очень хороший вопрос, но, пожалуйста, потерпите меня на минутку.
Чтобы представить его в перспективе, я использую Запомнить шаблон , чтобы сохранить значения свойств ввода строки CMD, и столкнулся с проблемой планирования моих 25+ настраиваемых действий для сохранения предоставленных свойств строки CMD перед AppSearch, так как Помните, что Pattern полагается на предоставленные CMD значения свойств, сохраненные до AppSearch. Полученное сообщение об ошибке выглядит следующим образом:
ошибка LGHT0179: таблица InstallUISequence содержит действие
'SaveCmdLine_SERV ICE_ACCOUNT', который не может иметь уникальную последовательность
номер, потому что это запланировано до или после действия 'AppSearch'.
До или после этого действия недостаточно места для назначения
уникальный порядковый номер. Пожалуйста, запланируйте одно из действий
иначе, чтобы он был в положении с большей последовательностью
номера доступны. Обратите внимание, что порядковые номера должны быть
целое число в диапазоне 1 - 32767 (включительно).
При проверке MSI, скомпилированной с использованием Orca, Sequence for AppSearch равен 50. Трудно найти документацию о таблице MSI Sequence, если что-нибудь вообще есть, но согласно ссылке из этого SO-вопроса , AppSearch должен иметь Последовательность 400. Обходной путь, который я использую, - это смещение AppSearch к большему порядковому номеру при проверке генерируемого MSI с использованием Orca. Что, кажется, хорошо.
Но 50 - это довольно низкое число, почему оно установлено на 50 вместо 400? Это управляется API установщика Windows или Wix?
Обновление: После обновления AppSearch до последовательности 400 я сталкиваюсь с проблемой, когда использование следующего кода с использованием начальной загрузки для требования .Net 4.5 завершится неудачей.
<Chain>
<PackageGroupRef Id="NetFx451Redist" />
<MsiPackage Name="$(var.OutputName).msi" SourceFile="MyInstaller.msi" DisplayInternalUI="yes" />
</Chain>
При проверке, похоже, мне нужно запланировать LaunchConditions
из порядкового номера 100 в порядковый номер 600, чтобы это продолжалось после AppSearch
, чтобы предварительный запрос проверки .Net framework все еще работал. Я думаю, что это, вероятно, одна из причин, по которой AppSearch
был запланирован так рано WiX.