Незначительное обновление с Wix Patching
У меня есть установщик для Wix, который устанавливает программу для версии, которую я успешно сделал исправления для достижения следующего обновления:
1.0.0 -> 1.0.1
1.0.0 -> 1.0.2
1.0.1 -> 1.0.2
Это работает, мне приходилось каждый раз создавать новые MSP-файлы с версии 1.0.0 до целевого номера сборки. Итак, насколько я понимаю, как патч работает за кулисами, так это то, что если у меня изначально был патч с 1.0.0 до 1.0.1, то я создал новый, чтобы перейти с 1.0.0 до 1.0.2, если бы мне нужно было запустить новый патч, старый патч будет удален, а новый заменит его.
Если мое понимание правильное, то это означает, что файлы исправлений будут продолжать увеличиваться в размере по мере того, как вы меняете код, поэтому я хотел бы найти решение, чтобы противостоять этому, когда в какой-то момент я увеличу младшую версию и начну процесс исправления заново,
Например, я хотел бы сделать это:
1.0.0 -> 1.0.12 могут быть обработаны с помощью patch1.msp. Then I create a patch2.msp which would start creating patches based off of version 1.0.12. An example upgrade path might then look like:
1.0.0 -> patch1.msp -> 1.0.12 -> patch2.msp -> 1.1.0 -> patch3.msp 1.1.0 -> 1.1.x
Есть ли способ сделать это? Or would I need to reinstall with a .msi file and continue to patch from there?
2 ответа
Во-первых, установка заменяющего MSP не удаляет замененные MSP. Замененный MSP просто помечается как замененный (неактивный). Если впоследствии вы удалите заменяющий MSP, ранее замененный MSP будет активирован повторно.
Чтобы удалить MSP, вам нужно использовать более старый метод устаревания, но я действительно не рекомендую этого. Мало того, что им трудно управлять, это также означает, что, например, если вы исправили ошибку безопасности в предыдущем удаленном патче, когда удаляется более новый устаревший патч, дыра в безопасности не исправляется. Это прекрасное дополнение, появившееся с MSI 3.0.
На ваш вопрос, однако, я не рекомендую это. Лучше всего, чтобы MSP ориентировались на базовый уровень. Да, потенциально они могут стать немного больше, но только если вы добавляете контент. Если более новые версии просто обновляют наборы файлов или других ресурсов, MSP, предназначенный для одного MSI, никогда не должен расти больше, чем базовый MSI (ну, MSI + внешние CAB, поскольку CAB встроены в MSP и всегда должны быть). См. https://blogs.msdn.microsoft.com/heaths/2007/03/30/small-updates-should-usually-target-a-single-baseline/ для получения дополнительной информации о небольших обновлениях MSP и https://blogs.msdn.microsoft.com/heaths/2006/06/14/cumulative-service-packs-with-minorupdatetargetrtm/ о том, как поддерживать таргетинг на единый базовый уровень с незначительными обновлениями MSP.
Это возможно, хотя. При создании каждого патча вам нужно сохранять MSI-обновления, поэтому, когда вы создаете MSI версии 1.0.1 для эффективного сравнения с 1.0.0 для построения MSP, то при создании следующего MSP вам нужно использовать версию 1.0.1 против 1.0.2. Эти MSP должны быть незначительными обновлениями MSP, хотя. Это означает, что свойство ProductVersion включено в преобразование создания патча; в противном случае представление MSI 1.0.0 + MSP 1.0.1 не изменит ProductVersion, поэтому MSP 1.0.2 никогда не будет применяться. Вы должны начать понимать, где это становится трудно поддерживать для вас (не говоря уже о том, что клиент вынужден устанавливать каждую предыдущую версию MSP, что для них тоже не очень удобно, если они только начинают работать с вашей RTM).
В итоге, сделайте это проще для ваших клиентов. Просто выберите ту же базовую линию, используя свойство MinorUpdateTargetRTM в таблице MsiPatchMetadata самого MSP.
По моему опыту, обычный путь заключается в том, что в какой-то момент вы создаете серьезное обновление MSI (см. Элемент mainupgrade WiX). Этот MSI с новым ProductCode и версией, большей, чем последняя версия патча (например, 2.0.0), обновит все версии между 1.0.0 и 1.0.12. Затем вы начинаете исправление на основе продукта 2.0.0.
В патчах есть опции для патча, заменяя каждый файл целиком или бинарным патчем каждого файла - я не уверен, какой вы используете, но, очевидно, если вы сделаете небольшой патч для огромного файла, патч будет больше, чем если patch - это двоичное обновление этого файла.