Когда обрабатывать службы в установщике MSI Таблица InstallExecuteSequence - PullRequest
1 голос
/ 09 марта 2019

Я хочу записать файл преобразования (.mst) в существующий файл установщика (.msi), чтобы правильно управлять службой, которая является частью установки. То есть исполняемый файл службы является частью MSI, но MSI не «знает», что это служба. Предопределенная InstallExecuteSequence работает так:

Action                  Condition         Sequence
...
InstallValidate         <null>            1400
RemoveExistingProducts  AI_UPGRADE<>"NO"  1450
InstallInitialize       <null>            1500
...
StopServices            VersionNT         1900
DeleteServices          VersionNT         2000
...
RemoveFiles             <null>            3500
...
InstallFiles            <null>            4000
...
InstallServices         VersionNT         5800
StartServices           VersionNT         5850
...
InstallFinalize         <null>            6600

Первое, что мне нужно было сделать в моем MST, это добавить подходящие записи в (изначально пустые или даже не включенные) таблицы ServiceControl и ServiceInstall. Все идет нормально. Однако теперь у меня есть сомнения относительно InstallExecuteSequence и того, стоит ли мне перемещаться по позициям четырех связанных с сервисом действий:

Документация говорит о RemoveExistingProducts, как указано выше:

В этом случае программа установки полностью удаляет старые приложения перед установкой новых приложений. Это неэффективное размещение для действия, потому что все повторно используемые файлы должны быть повторно скопированы.

Это меня несколько смутило. Не выполняется ли удаление и копирование файлов (повторно используемых или нет) в действиях RemoveFiles и InstallFiles (и, возможно, нескольких связанных)? Каким-то образом приведенная выше цитата, кажется, предполагает, что (в случае обновления) старая версия моего exe-файла службы будет заменена новой версией до остановки службы (и даже до того, как InstalInitialize начнет транзакцию установки?!?) Означает ли это, что я должен рассмотреть вопрос о перемещении действия RemoveExistingProducts в моем MST? Или переместить действия «Остановить / удалить службы» до RemoveExistingProducts и, соответственно, действия «Установить / запустить службу» после завершения транзакции установки, т. Е. После InstallFinalize? Это также не кажется правильным - конечно, эти действия должны быть защищены транзакцией (особенно в случаях, когда транзакция должна быть откатана во время первой установки или полной деинсталляции).

Мое инстинктивное чувство заключается в том, что я не должен волноваться, и все в порядке, как есть, и я просто что-то неправильно понимаю. Так что я был бы благодарен, если бы кто-то мог просветить меня ...

1 Ответ

1 голос
/ 10 марта 2019

Это будет немного поспешно, позже мы вернемся назад - без проверки качества:


Удаление : RemoveExistingProducts фактически использует InstallExecuteSequence существующей установки для вашего продукта - чтобы удалить его как часть крупного обновления процесса, который вы бегут. Так что "внутри" RemoveExistingProducts в целом происходит удаление старой версии вашего продукта. В пределах другая версия InstallExecuteSequence фактическая файловые операции выполняются RemoveFiles, как вы подозреваете, затем управление возвращается в исходное местоположение в вашем новом MSI Как Другими словами, вызов функции - она ​​возвращается туда, где была деинсталляция прибег.

Служба : я бы сохранил последовательность, которую вы показываете в своем вопросе.

  • StartServices и InstallServices должно произойти после RemoveFiles и InstallFiles
  • StopServices и DeleteServices должно произойти до InstallFiles и InstallServices.

RemoveExisting Productct Placement : если вы измените размещение RemoveExistingProducts, вы будете переключаться между различными вариантами последовательности для значительного удаления и повторного установки обновления:

  • Ранний REP : Полное удаление старой версии, а затем запуск новой установки для завершения обновления продукта. Это прощение ошибок ссылок на компоненты и часто используемое.
  • Позднее REP : Ваш новый продукт устанавливается поверх всех обновленных файлов, а затем удаляются устаревшие файлы и удаляются параметры реестра и т. Д. Это приводит к обновлению, которое эффективно устанавливается как патч. Он очень уязвим для ошибок ссылок на компоненты и часто от него отказываются, если вы не знаете на 100%, что вы можете и не можете делать.

Основное обновление : существует несколько разновидностей вышеупомянутых двух общих опций секвенирования, и документация WiX перечисляет их здесь . Это атрибут Schedule. Есть много вариантов - каждый из которых имеет важные особенности и факторы: afterInstallValidate, afterInstallInitialize, afterInstallExecute, afterInstallExecuteAgain, afterInstallFinalize. Пожалуйста, внимательно прочитайте связанную документацию .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...