Что заставляет обновление MSI не обновлять компонент в установщике?

Question

(РЕДАКТИРОВАТЬ: Вопрос изменен.)

У меня есть продукт с установщиком, который был создан InstallShield 2010 и, похоже, все учетные записи устанавливают просто как «новую» установку.

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

Когда некоторые пользователи запускают установщик в системе, в которой мой продукт уже присутствует, им предлагается пользовательский интерфейс режима обновления («Вы хотите обновить?» И т. Д.), И кажется, что установщик завершает работу. Однако обновленные файлы не всегда перезаписывают старые файлы до тех пор, пока впоследствии не будет запущена установка восстановления, особенно если номер версии не изменился, и теперь есть доказательства того, что пометка содержимого компонента с помощью принудительной перезаписи не выполняется. не меняйте это поведение.

Что здесь происходит? Могу ли я получить лучший результат? Нужно ли менять код пакета при каждой проверке продукта или обновлении компонента? (Изменить: Код пакета меняется каждый раз, когда я собираю релиз, поэтому это не является причиной проблемы.)

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

Answer 1

Вы, безусловно, должны менять PackageCode при каждой сборке. На самом деле, по умолчанию InstallShield имеет параметр сборки, который делает именно это.

На самом деле, раздел справки MSDN Коды пакетов говорит:

Неидентичные MSI-файлы не должны иметь одинаковый код пакета. Важно изменить код пакета, потому что это основной идентификатор, используемый установщиком для поиска и проверки правильности пакета для данной установки. Если пакет изменяется без изменения кода пакета, установщик может не использовать более новый пакет, если оба они по-прежнему доступны для установки.

Вот почему вы получаете опыт обслуживания интерфейса вместо обновления.

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

Answer 2

В ответе @ ChristopherPainter выше я также узнал, что InstallShield имеет настройку для автоматической генерации кода пакета, но он не сказал, где это было.Так что для всех, кто ищет его:

Этот параметр находится в разделе Media / Releases / (название выпуска), конфигурация продукта, вкладка General.Там вы найдете «Создать код пакета» и убедитесь, что для него установлено значение «Да».

Answer 3

Установщик делает то, что должен, основываясь на неизменной информации о версии файла.

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

Самый простой способ - установить свойство REINSTALLMODE. Вы можете установить его на «amus», что приведет к переустановке всех файлов. См. MSDN - http://msdn.microsoft.com/en-us/library/aa371182%28v=vs.85%29.aspx

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

Несколько более сложным способом, который позволяет вам контролировать на уровне отдельных компонентов, является использование настраиваемого действия. Вызовите MsiSetComponentState, чтобы явно установить каждый из ваших компонентов в любое желаемое состояние. http://msdn.microsoft.com/en-us/library/aa370383%28v=VS.85%29.aspx

Насколько я помню, ваше пользовательское действие должно выполняться после CostFinalize, поэтому установщик не удаляет ваши обновления.

Answer 4

Когда установщик Windows решает, устанавливать ли ваш компонент, он сначала проверяет, присутствует ли ресурс keypath. Если это так, ни один из ресурсов в компоненте не установлен. (Я предполагаю, что Installshield помещает каждый файл в отдельный компонент, а путь к ключу - это файл.)

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

edit : почему исправление устраняет проблему: я полагаю, что оно переустановит все компоненты из кэшированного MSI-файла в c:\windows\installer независимо от наличия / версии ресурса keypath. Это кажется логичным, поскольку это единственный способ убедиться, что поврежденные файлы восстановлены. (Я не могу сразу найти четкую ссылку на MSDN, чтобы поддержать это, извините.)

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