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

(EDIT: вопрос изменен.)

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

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

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

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

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


windows-installer installshield installshield-2010
person Rob Perkins    schedule 14.01.2011    source источник

Ответы (4)


arrow_upward
3
arrow_downward

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

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

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

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

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

person Christopher Painter    schedule 15.01.2011
comment
Если для этого есть настройка InstallShield, мне еще предстоит найти ее после 11 лет использования InstallShield (я использовал InstallScript до самой последней основной версии). Можете ли вы предложить некоторые ресурсы для изучения этого, которые менее отвратительно бессвязны, чем MSDN документация? - person Rob Perkins; 15.01.2011
comment
РЕДАКТИРОВАТЬ: я нашел настройку, и для всех моих выпусков в проекте установлено значение «Да». Так что причина моей проблемы, я думаю, не в неизменном коде пакета. Я поставлю другой вопрос как вопрос сам по себе. - person Rob Perkins; 15.01.2011
comment
Похоже, вы обновляете PackageCode и создаете SEtup.exe, и результатом является незначительное обновление. Вы должны следовать правилам компонента до буквы в этой ситуации. - person Christopher Painter; 15.01.2011
comment
Прочтите msdn.microsoft.com/en-us/ library/aa368599(v=vs.85).aspx и msdn.microsoft.com/en-us/library/aa368267(v=vs.85).aspx и все различные ссылки с этих страниц. - person Christopher Painter; 15.01.2011
comment
Да, но я имел в виду ужасно бессвязную документацию MSDN. ;-) - person Rob Perkins; 17.01.2011
comment
Эта часть не так уж и плоха. На самом деле в нем есть несколько хороших таблиц и блок-схем, чтобы объяснить, что происходит. Вы также можете зарегистрировать установку и прочитать, что она говорит вам и почему. - person Christopher Painter; 17.01.2011
comment
Это оправдает ответ @Christopher Painter: сейчас я дошел до того, что мне нужно обновить программу установки, и AMUS вызывает у меня серьезную изжогу. Теперь я должен пройти и исправить все компоненты. Я не думаю, что Windows Installer и Installshield очень удобны даже для опытного программиста. - person Rob Perkins; 20.01.2012

arrow_upward
2
arrow_downward

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

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

person Jeff    schedule 02.07.2014

arrow_upward
1
arrow_downward

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

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

Самый простой способ — установить свойство 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, чтобы установщик не уничтожил ваши обновления.

person Ed.    schedule 15.01.2011
comment
Парадоксально, что другое программное обеспечение, обычно устанавливаемое вместе с нашим, от совершенно другой компании, отменяет компонент, который мы включаем, но я думаю, что это решение сработает для нас. Спасибо! - person Rob Perkins; 17.01.2011
comment
Это оправдает ответ @Christopher Painter: сейчас я дошел до того, что мне нужно обновить программу установки, и AMUS вызывает у меня серьезную изжогу. Теперь я должен пройти и исправить все компоненты. Я не думаю, что Windows Installer и Installshield очень удобны даже для опытного программиста. - person Rob Perkins; 20.01.2012

arrow_upward
0
arrow_downward

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

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

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

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

person Wim Coenen    schedule 15.01.2011
comment
Это звучит правильно; Я использую их вспомогательные функции для запуска проекта, а затем при необходимости изменяю некоторые элементы, добавляя функциональные возможности, такие как пара настраиваемых действий. Но почему восстановительная установка запускается через панель управления «Программы и компоненты», а затем исправляет ситуацию, когда установка обновления не удалась? Разве поведение не должно быть одинаковым в обоих случаях? - person Rob Perkins; 15.01.2011