Wix - Отложенное настраиваемое действие завершается неудачно при обновлении, в результате чего продукт полностью удаляется - PullRequest
0 голосов
/ 27 августа 2018

Настройка

Итак, у меня есть пользовательское действие, помеченное как отложенное и выполняемое перед InstallFinalize. Это выглядит так:

  <CustomAction Id="CADeferred"
                BinaryKey="binaryCustomActions"
                DllEntry="CADeferredMethod"
                Execute="deferred"/>

  <InstallExecuteSequence>
  ...
  <Custom Action="CADeferred"
          Before='InstallFinalize'>Not Installed or Upgrading</Custom>
  </InstallExecuteSequence>

И у меня в настоящее время установлена ​​версия 1.0 в компьютерной среде, и она полностью функциональна. Затем я использую MSI версии 2.0 для обновления.

Проблема, с которой я сталкиваюсь

При выполнении обновления это пользовательское действие может завершиться ошибкой и возвращает ActionResult.Failure. Когда это происходит, программа установки завершается с ошибкой и говорит:

"Мастер настройки продукта преждевременно завершил работу из-за ошибки. Система не была изменена. Чтобы установить эту программу позже, снова запустите мастер установки. Нажмите кнопку Готово, чтобы выйти из программы установки. Мастер ".

Как только я нажму Готово. Я проверил, что сам продукт был полностью удален из компьютерной среды. Как будто это было удалено по существу.

Я надеялся, что произойдет откат до версии 1.0, как это было до обновления.

То, что я пытаюсь выполнить

Если такой сценарий происходит, мне нравится, когда установщик выполняет откат до версии 1.0 в среде.

Что я уже сделал

Я изучил в Google дополнительную информацию о том, как работает InstallFinalize, как работают откаты и т. Д.

Из моего исследования наличие отложенного настраиваемого действия для запуска перед InstallFinalize - это путь к настраиваемому действию, которому необходимо изменить состояние среды. Помимо возможности использовать новые файлы в новом установщике, например в DLL, потому что он запускается «внутри» шага InstallFinalize. Поскольку он определен до InstallFinalize, я подумал, что его откат вернет систему к предыдущей установленной версии продукта.

Я пытался превратить его в немедленное настраиваемое действие для запуска после InstallFinalize, но это плохо. Если это не удается, продукт все еще обновляется до версии 2.0. Что странно. К тому же я знаю, что это осуждается. Поэтому я перешел к отложенному настраиваемому действию для запуска перед InstallFinalize.

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

Так что я довольно озадачен. Любая помощь или направление будет очень цениться. Если я не достаточно ясен, не стесняйтесь просить больше разъяснений. Пожалуйста и спасибо.

1 Ответ

0 голосов
/ 27 августа 2018

Пожалуйста, прочитайте следующее MSI SDK описание: RemoveExistingProducts Action . По сути, размещение стандартного действия RemoveExistingProducts будет влиять на то, как работает откат, и в действительности, если он работает вообще. Это стандартное действие запускает удаление старой установки во время крупного обновления - которое под капотом на самом деле является не обновлением, а удалением старого продукта и установкой нового продукта - с несколькими различными «разновидностями» последовательности - в Другими словами, что происходит в первую очередь, удаление или установка.

Позднее RemoveExistingProducts секвенирование позволяет выполнить откат (подробности в статье SDK, ссылки на которую приведены выше). Для позднего размещения RemoveExistingProducts для правильной работы необходимо соблюдать осторожность, чтобы правила компонента не были нарушены, иначе файлы будут отсутствовать после обновления, если вы запустили последовательность удаления поздно. Это связано с тем, что в этом случае новая версия устанавливается как исправление. Он исправляет измененные файлы, а затем удаляет все устаревшее. В сценарии ранней деинсталляции вы «отсоединяете» себя от этих проблем со счетчиком ссылок - старый продукт полностью исчез до установки нового - и, следовательно, вы не сможете откатиться к нему (если не переустановите его вручную). Другими словами: рано RemoveExistingProducts это больше, чтобы прощать ошибки проектирования установки - и, следовательно, больше используется в реальном мире.

Конфигурация основного обновления определяется элементом MajorUpgrade или Элементами обновления .


Некоторые ссылки :

...