Почему рекомендуется ограничивать развертывание файлов в профиле пользователя или HKCU?

Почему рекомендуется ограничивать развертывание файлов в профиле пользователя или HKCU из моего MSI или файла установки?


Развертывание является важной частью большинства разработок. Пожалуйста, дайте этому контенту шанс. Я твердо убежден в том, что качество программного обеспечения может быть значительно улучшено благодаря небольшим изменениям в дизайне приложений, чтобы сделать развертывание более логичным и надежным - вот что такое "ответ" - разработка .. p >


Это вопрос типа Q/A, разделенный на ответ, который стал слишком длинным: Как избежать общих недостатков дизайна в моем решении по развертыванию WiX/MSI?.

Ответ 1

Как указано выше , этот раздел был разделен на существующий ответ с более широкой областью: Как избежать общих недостатков дизайна в моем WiX/MSI решение для развертывания? (ответ, призванный помочь разработчикам лучше принимать решения о развертывании).


9. Излишнее использование файла для каждого пользователя и реестра.

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

Существует несколько способов "исправить", но вся проблема развертывания файлов и настроек для каждого пользователя несколько запутана по нескольким основополагающим причинам:

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

Нет реальных ответных ответов, но есть несколько альтернативных способов решения "проблем". Мои предпочтительные параметры - 2 и 3, так как я не думаю, что установщик Windows должен развернуть, отслеживать или пытаться модифицировать или еще хуже, удалять данные пользователя и настройки вообще - это данные пользователя, которые не следует вмешиваться в:

9.1 Использование самонастройки установщика Windows или аналогичного

Первый вариант - получить настройки и файлы, а ключи реестра HKCU правильно развернуты через саму настройку или функции, подобные настройке. Существует два основных способа сделать это: полагаться на установщик Windows " самостоятельный ремонт", как правило, запускается рекламируемым ярлыком или с помощью Microsoft Active Setup.

  • Саморемонт - это то, что происходит, когда вы запускаете ярлык для запуска своего приложения, а установщик Windows запускается, и вы видите индикатор выполнения, пока "что-то" устанавливается. Обычно добавляются записи реестра HKCU и файлы профиля пользователя.

  • Существует и другая альтернатива для достижения этой цели, она называется Active Setup и также является функцией Microsoft. Он по существу регистрирует "что-то запущенное" для запуска один раз для пользователя при входе в систему. Это можно использовать для настройки данных для каждого пользователя. Active Setup позволяет выполнить "что-нибудь выполнимое" - например, копию файлов в профиль пользователя..

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

  • Хотя настройка пользовательских данных с самообслуживанием и Active Setup - это "установленные" методы для правильной работы приложений, кажется неправильным отслеживать пользовательские данные с компонентами установщика Windows. Зачем? Поскольку это действительно пользовательские данные, которые не должны вмешиваться с инициализацией.

  • В соответствии с этим я честно беру на себя всю проблему: старайтесь избегать развертывания отдельных данных или ключей реестра и значений вообще, и это то, что описано далее, как два других пользовательских данных методы развертывания.

9.2 Инициализация приложений пользовательских данных

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

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

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

  • Общий вывод заключается в том, что ваша установка должна подготовить ваше приложение для первого запуска, он не должен настраивать среду пользовательских данных и настроек. Все файлы профиля пользователя и настройки HKCU должны быть отменены приложением в случае, если они отсутствуют при запуске - это дает гораздо более надежное приложение, которое легче тестировать для персонала QA. Это особенно важно для терминальных серверов, где самовосстановление не разрешено запускать вообще. В таких случаях данные приложения будут отсутствовать, если вы полагаетесь на самовосстановление, чтобы помещать данные пользователя на место.

9.3 "Облако" или хранилище данных для пользовательских настроек

Чтобы сделать шаг вперед в сегодняшней "облачной среде" - и , это, на мой взгляд, предпочтительный вариант. Почему ваше приложение должно быть ограничено файлами и ключами реестра и значениями? Почему бы не сохранить все пользовательские настройки в базе данных решений?

  • Полный доступ, контроль и сохранение для всех настроек без каких-либо проблем с развертыванием.

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

  • Мы достаточно долго боролись с перемещающимися профилями, испорченным реестром пользователей, неправильными файлами данных профиля пользователя и т.д.. Разработчики, избавитесь от многих проблем и создайте себе новые проблемы с управлением базой данных вместо проблем с развертыванием - и начните кричать на совершенно новую группу людей!: -).

  • Настройки в базах данных:

    • Не страдает от "проблем с двумя источниками". Существует один экземпляр, и он обновляется в режиме реального времени. Не похоже на проблемы синхронизации, наблюдаемые с помощью профиля пользователя и "роуминга".

    • Проверяемый, управляемый и патчевый

    • Revisable (управление версиями - может вернуть старые настройки)

  • Вы даже можете "настроить" все пользовательские настройки из своей установки, запустив сценарии базы данных как часть развертывания, но если вы находитесь в корпоративной среде - это не мысль просто поднять билет, а затем попросите администратора базы данных запустить сценарии обслуживания с правильной поддержкой транзакций и откатом более привлекательным?

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

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

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