Суть : я много писал, и ничто не имело такого смысла. Позвольте мне вместо этого попытаться сделать его коротким: Don't write registry values that your application might change. Вот что я могу сделать, чтобы стать лучше
установить с настройками приложения управления в будущем: 1)
use a custom REINSTALLMODE, чтобы не перезаписывать какие-либо ключи реестра в этом обновлении, и тогда я бы 2) modify the application, чтобы
скопируйте ключи реестра HKCU в новое место и никогда не трогайте
их с тех пор по вашей настройке. 3) Вы также должны update your application to be able to write all HKCU keys for your application if they are missing - на основе шаблона только для чтения
настройки хранятся в HKLM - или вы пишете их из внутренних значений по умолчанию
хранится в application.exe .
Таким образом, вам не понадобятся никакие настройки HKCU, записанные вашей установкой в будущем, и не будут возникать помехи для измененных значений.
Существуют способы применения новых значений - если вам нужно .
Я также оставлю ниже.
Реальный мир : Этот "overwrite registry settings on upgrade problem", на мой взгляд, является MSI-дизайном . Или, как мне нравится называть это: Жалоба MSI Festivus (для просмотра контекста необходимо посмотреть видео).
Чтобы надежно избежать этой проблемы, я хочу предложить вам рассмотреть этот вариант:
Устранить параметры реестра развертывания : Generally you should not write registry settings from your setup that are ever changed by your application.
HKLM keys: я записываю только настройки только для чтения в HKLM из настройки и разрешаю их переопределять с помощью msiexec.exe командная строка. А затем я читаю их обратно при обновлениях, используя AppSearch или пользовательское действие - или не совсем - в зависимости от того, что имеет смысл для бизнес-логики и варианта использования.
HKCU keys: Я бы предпочел полностью удалить все ключи HKCU из развертывания в более новой версии и записать ключи реестра по умолчанию через само приложение - используя его последовательность запуска. По сути, это всегда устраняет множество проблем с развертыванием . Вы даже можете сохранить параметры копирования приложения, которые вы записали в реестре, доступном только для чтения, в его активный «живой» куст. Например, вы копируете значения по умолчанию из раздела реестра, доступного только для чтения, в HKLM.
Это общий подход, который я хотел бы использовать, чтобы «защитить» мое приложение от помех развертывания в отношении данных для каждого пользователя - будь то ключи реестра в HKCU или на основе userprofile. Для некоторых приложений это невозможно. Например те, у которых нет exe с последовательностью запуска.
Но подождите, даже если вы сможете использовать этот подход и удалить компоненты, на которых размещены записи реестра в вашем новом MSI, удаление и переустановка (во время крупного обновления - которое необходимо удалить компоненты) вашего пакета затем вырвется. ключи реестра, если вы не установили их в качестве прямых.
Иногда я прихожу к выводу, что мне нужно оставить старые компоненты и скопировать новые для записи в новый раздел реестра ИЛИ в другие имена значений реестра для хранения новых значений.
Помните шаблон свойств : Хотя для WiX, а не для Installshield, «Помните шаблон свойств» Роба Меншинга - урок о том, как использовать AppSearch. Идея та же самая в Installshield. Вы читаете свойства обратно с помощью AppSearch во время сценариев обслуживания и обновления - в этом отношении свежая установка.
Роб прекрасно иллюстрирует иронию этого " запомнить шаблон " в том, как он будет переопределять любые новые значения, которые вы указали в командной строке msiexec.exe, если вы не предпримете шаги для Избегайте этой проблемы (или ваш сценарий позволяет игнорировать эту конкретную проблему - что редко бывает безопасно). Пожалуйста, прочитайте статью для всей истории.
Installshield : В installshield вы определяете записи AppSearch в представлении поиска системы . Диалоги здесь должны быть в значительной степени понятны, так как вы просто указываете, какие разделы реестра или записи из файлов настроек должны быть считаны в любое свойство, в которое вы указываете их для чтения. Диалоги являются «волшебниками», поэтому вы просто нажимаете на них и создаете AppSearch.
Примечание! : Очень часто раздражает забыть сослаться на правильный куст реестра, основанный на битности (32 против 64-бит):
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla FirefoxHKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Mozilla\Firefox
Это может вызвать некоторое подлинное и повторное замешательство - по крайней мере, в моем мире. И это настолько глупая проблема, что мы все хотим, чтобы она не теряла ни минуты нашего времени.
Вы можете реализовать пользовательские действия, предложенные Робом, чтобы AppSearch не стирал значения свойств, поступающие из командной строки. Или я полагаю, вы могли бы игнорировать это, если рассматриваемые свойства не должны быть установлены из командной строки? Я полагаю, что это возможно.
Подходы с настраиваемыми действиями : мне это не нравится, но я их кратко упомяну.
Write Registry Settings With Custom Actions: Некоторые предпочитают напрямую записывать параметры реестра с помощью настраиваемых действий, поскольку затем они могут добавить логику в настраиваемое действие для записи новых значений по своему усмотрению, а в противном случае Держите msiexec.exe отдельно от значений и никогда не сбрасывайте их неожиданно. Логически это не самый плохой подход, но вы также, вероятно, становитесь своим злейшим врагом, когда добавляете риск, так как пользовательские действия сложны для правильного выполнения, а также для правильной подготовки и последовательности действий. Настраиваемые действия являются основной причиной сбоя развертывания .
Backup / Restore - or "Preserve Values Custom Actions": Вместо того чтобы писать точечные настройки напрямую, используя настраиваемые действия, некоторые люди используют настраиваемые действия для резервного копирования, а затем для массового восстановления настроек реестра на конец установки. Не очень хороший подход, на мой взгляд. Очень неуклюжий и склонный к перезаписи ошибок сам по себе. Последовательность и согласование таких пользовательских действий также могут стать очень сложными .
И есть другие подходы.