Если он определен Wix, для меня, на мой взгляд, если это меня достаточно раздражает, поскольку у нас есть несколько проектов, использующих один и тот же шаблон, я мог бы просто отправить отчет об ошибке и в то же время изменить только порядковый номер AppSearch в нашем Проект MSI.
е хороший вопрос, но, пожалуйста, потерпите меня.
Чтобы поместить это в перспективу, я используюЗапомнить шаблон чтобы сохранить значения входных свойств строки CMD, и столкнулся с проблемой планирования моих 25+ настраиваемых действий для сохранения предоставленных свойств строки CMD перед AppSearch, так как Remember Pattern полагается на предоставленные CMD значения свойств, сохраненные до AppSearch. Полученное сообщение об ошибке выглядит следующим образом:
ошибка LGHT0179: таблица InstallUISequence содержит действие «SaveCmdLine_SERV ICE_ACCOUNT», которое не может иметь уникальный порядковый номер, поскольку оно запланировано до или после действия «AppSearch». До или после этого действия недостаточно места для назначения уникального порядкового номера. Пожалуйста, запланируйте одно из действий по-другому, чтобы оно было в положении с большим количеством доступных порядковых номеров. Обратите внимание, что порядковые номера должны быть целыми числами в диапазоне от 1 до 32767 (включительно).
После проверки MSI, скомпилированного с использованием Orca, Sequence for AppSearch равен 50. Трудно найти документацию о таблице MSI Sequence, если вообще что-то есть, но по ссылке изэто ТАК вопросУ AppSearch должна быть Sequence o, f 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.