Как мне обращаться с обновлениями продукта в установщике WiX?

Question

У меня достаточно большой установщик WiX (250 Мб плюс), и я пытаюсь найти подходящую стратегию обновления.

Большинство файлов в установщике не изменится, и мы бы предпочли не распространять весь пакет, когда изменился только один или два файла.

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

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

Я проверил это, используя "torch", чтобы создать файл "wixmst" на основе различий между двумя файлами "wixpdb", а затем создал из него патч. Тем не менее, я обнаружил, что могу патчить только из одной версии в другую (например, с 1.0.0 до 1.0.1, затем с 1.0.1 до 1.0.2, но не с 1.0.0 до 1.0.2). Можно ли выбрать минимальную версию для патча и поддерживать любую версию над ним?

Answer 1

Исправление - это боль, поэтому будьте готовы ко многим из них, когда вы научитесь справляться с этим. Вот еще одна стратегия, которая может работать на вас. Разделите ваш MSI на 2 MSI (Microsoft называет это Микропакеты). У вас должен быть базовый MSI, который содержит основную часть вашего контента, который, как ожидается, не изменится, и второй MSI, который намного меньше, который содержит ваши файлы, и вы ожидаете, что он будет высоким.

Затем используйте Burn - загрузчик, чтобы обрабатывать их вместе и удалять вместе. Это похоже на то, что делает Visual Studio.

Теперь вы можете просто отправить основные обновления вашего второго MSI.

Answer 2

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

1. Установить MSI (v1.0)
2. Установить MSP (v1.0 - v1.1)
3. Удалить MSP (вернуться кv1.0), затем установите msp (v1.0 - v1.2)

Для получения дополнительной информации об удаляемых исправлениях см. документацию wix: http://wix.sourceforge.net/manual-wix3/patch_restrictions.htm и документацию Windows: http://msdn.microsoft.com/en-us/library/aa372102.aspx.

Обратите внимание, что для создания неустановимых исправлений существуют определенные ограничения, и вы должны использовать WiX 3.0 или выше.

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

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

Answer 3

В то время как ответ Кристоферса удивителен тем, что он предлагает загрузчик wix, я бы не рекомендовал делать серьезные обновления для пакета с высоким уровнем оттока.Проблема в том, что после того, как вы выполнили свой патч начальной загрузки, который внутренне выполняет значительное обновление ваших летучих библиотек в HighChurn.msi с версии v1.0 до v1.1, загрузчик, насколько мне известно, не будет переустанавливать предыдущуюпакет HighChurn.msi в v1.0.

Существует другой путь: вы, безусловно, можете создавать патчи, предназначенные для выпуска вашего основного пакета.Учитывая то, что вы написали, я не совсем уверен, но если ваш патч 1.2 можно применить только к 1.1, то вы, вероятно, понизили свой 1.2 только против 1.1, а не против 1.0.

Вот аккуратное руководство, каксоздать патчи: https://www.firegiant.com/wix/tutorial/upgrades-and-modularization/patchwork/

Следуйте этому руководству, сделайте замену патчей ([PatchFamily / @ Supersede], это сделает v1.2 недействительным все, что поставлено v1.1, поэтому вы в основном вынуждены сделать v1.2 patch v1.0, а не v1.1) и добавьте этот флаг к элементу patch, чтобы указать основной выпуск, даже если присутствуют более высокие версии: Patch / @ MinorUpdateTargetRTM = "yes" .Всегда сравнивайте свои патчи с установщиком релиза (HighChurn.msi v1.0), а не с установщиком, который вы использовали для патча (HighChurn.msi v1.1).

Конечно, в некоторых ситуациях вам может понадобитьсятребовать определенного обновления, установленного для исправлений: например, хорошо спланированная схема пакета исправлений / пакетов обновлений, в которой исправление 1.1.1 требует, чтобы пакет обновления 1.1 был установлен поверх выпуска 1.0.

Последнее слово о исправлении вашего volatiledata (я предполагаю, что версионные библиотеки здесь): вы можете захотеть посмотреть, какие библиотеки вы можете заменить в патче.Затем вы можете создавать патчи с очень небольшим количеством данных, только предоставив измененным библиотекам более высокую версию.Если вы увеличите версию всех своих библиотек, все библиотеки будут исправлены, что приведет к более крупным исправлениям.Это может потребовать немного более сложного процесса сборки (Бог знает, что он сделал для нас).