Installshield Setup / Patch / Upgrade вопрос - PullRequest
1 голос
/ 23 декабря 2009

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

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

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

Ответы [ 3 ]

1 голос
/ 23 декабря 2009

Это действительно сложный материал, но нет лучшего источника, чем документация установщика Windows: Обновление и обновление

заплат

0 голосов
/ 04 января 2015

Когда делать то, что (то есть обновление против обновления против исправления) лучше всего объясняется установкой InstallShield здесь . Основываясь на фактах, упомянутых в таблице, описывающих, когда реализовывать какой тип обновления, следует решить, является ли это обновлением, обновлением или исправлением.

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

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

0 голосов
/ 14 ноября 2011

Предполагается, что на момент выпуска продукта (в данном случае установщика версия 1) установлена ​​система контроля версий.

Релиз-инженер сделал бы снимок состояния «Релиз-ветки», а затем переименовал его соответствующим образом для следующего выпуска (в данном случае установщик версии2).

Разработчики будут продолжать кодировать в аналогичной ветви (ветке Dev), которая имеет те же биты до даты выпуска.

Из этой ветки "Release / Dev" создается ветка HotFixes / Patches, а патчи выпускаются из ветки "Hot Fixes or Patches".

Эти патчи будут содержать логику, которая будет определять предварительные требования для установки. Например, для «patch1-version1» потребуется «Release version1» ... «patch2-version1» может потребоваться просто «patch1-version1» ... и т. Д.

Когда вы будете готовы создать второй выпуск "Release Version2", ветвь Release будет названа соответствующим образом и будет иметь все изменения из "Release Version1" + "All fixes" в ветке "Hot Fixes or Patches".

В этом новом выпуске потребуется логика для удаления предыдущего выпуска и установки нового.

СЕЙЧАС, новая ветка «Горячих исправлений» создается из современной «Ветки релизов», или изменения просто переносятся в ранее созданную ветвь «Горячих исправлений» и любые новые патчи для «Версии выпуска 2». теперь должен иметь обновленную логику, чтобы ТОЛЬКО разрешить установку в соответствии с новыми требованиями ... относящимися к "Release Version2".

Например, «Patch1-ReleaseVersion2» потребует наличия «Release Version2» ... аналогично, «Patch2-ReleaseVersion2», вероятно, потребует и «Release Version2» плюс первый выпущенный патч, или просто наличие первого патча выпущен, потому что базовый выпуск (Release Version2) также должен быть там.

Таким образом, учитывая этот стандарт, "patch1,2,3 ... n-ReleaseVersion2" никогда не следует устанавливать на сервер, на котором установлены исправления "Release Version1" + Zero / More, поскольку логика в установщике исправлений не будет ( или не должны) разрешить такую ​​вещь.

...