Когда и почему вы должны хранить данные в реестре Windows?

Question

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

Когда я пишу свои собственные приложения, что - если что-нибудь - я должен выбрать для размещения в реестре, а не в старомодных конфигурационных файлах, и почему?

Answer 1

• Первоначально (WIN3) конфигурация была сохранена в файле WIN.INI в каталоге Windows.
• Проблема: WIN.INI стал слишком большим.
• Решение (Win31): отдельные INI-файлы в том же каталоге, что и программа.
• Проблема: эта программа может быть установлена ​​в сети и доступна многим людям.
• Решение (Win311): отдельные INI-файлы в пользовательском каталоге Windows.
• Проблема: многие люди могут использовать общую папку Windows, и она все равно должна быть доступна только для чтения.
• Решение (Win95): Реестр с отдельными разделами для каждого пользователя.
• Проблема: реестр стал слишком большим.
• Решение (WinXP): большие блоки отдельных данных перемещаются в собственную папку Application Data пользователя.
• Проблема: подходит для больших объемов данных, но довольно сложна для небольших объемов.
• Решение (.NET): небольшое количество фиксированных данных только для чтения, хранящихся в файлах .config (Xml) в той же папке, что и приложение, с API для их чтения. (Чтение / запись или пользовательские данные остаются в реестре)

Answer 2

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

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

Любые настраиваемые параметры или требуемые библиотеки DLL и т. Д., Если они не являются общими, должны находиться в подкаталоге установочного каталога, чтобы вся установка легко перемещалась.

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

Answer 3

Политика Microsoft:

• До Windows 95 мы использовали INI-файлы для данных приложения.
• В эпоху Windows 95 - XP мы использовали реестр.
• В Windows Vista мы используем ini-файлы, хотя теперь они основаны на xml.

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

Answer 4

Когда - Вы вынуждены сделать это из-за унаследованной интеграции или из-за того, что системный администратор вашего клиента говорит «так будет», или из-за того, что вы разрабатываете на более старом языке, что усложняет использование XML.

Почему - прежде всего потому, что реестр не так переносим, ​​как копирование файла конфигурации, который находится рядом с приложением (и называется почти так же).

Если вы используете .Net2 +, у вас есть файлы App.Config и User.Config, и вам не нужно регистрировать библиотеки DLL в реестре, поэтому держитесь от них подальше.

Файлы конфигурации имеют свои проблемы (см. Ниже), но их можно закодировать, и вы можете изменить свою архитектуру.

• Проблема: для приложений требовались настраиваемые параметры.
• Решение: сохранить настройки в файле (WIN.INI) в папке Windows - используйте заголовки разделов для группировки данных (Win3.0).
• Проблема: файл WIN.INI стал слишком большим (и запутался).
• Решение: сохранить настройки в INI-файлах в той же папке, что и приложение (Win3.1).
• Проблема: нужны пользовательские настройки.
• Решение: хранить пользовательские настройки в пользовательских INI-файлах в пользовательском каталоге Windows (Win3.11) или в пользовательских разделах в INI-файле приложения.
• Проблема: безопасность - некоторые настройки приложения должны быть доступны только для чтения.
• Решение: Реестр с безопасностью, а также разделы, специфичные для пользователя и всего компьютера (Win95).
• Проблема: реестр стал слишком большим.
• Решение: Пользовательский реестр перемещен в user.dat в собственной папке «Данные приложения» и загружается только при входе в систему (WinNT).
• Проблема: в больших корпоративных средах вы подключаетесь к нескольким машинам, и вам нужно настроить EACH ONE.
• Решение. Различают локальные (локальные настройки) и перемещаемые (прикладные данные) профили (WinXP).
• Проблема: не удается xcopy развернуть или переместить приложения, как и остальные компоненты .Net.
• Решение: APP.CONFIG XML-файл находится в той же папке, что и приложение - легко читается, легко манипулирует, легко перемещается, может отслеживать изменения (.Net1).
• Проблема: по-прежнему необходимо хранить пользовательские данные аналогичным образом (т.е. развертывание xcopy).
• Решение: USER.CONFIG XML-файл в локальной или перемещаемой папке пользователя со строгой типизацией (.Net2).
• Проблема: файлы CONFIG чувствительны к регистру (не интуитивно понятны для людей), требуют очень специфических открывающих / закрывающих «тегов», строки подключения не могут быть установлены во время выполнения, проекты установки не могут записывать настройки (так же легко, как реестр), не может легко определить файл user.config, и пользовательские настройки будут удалены с каждой новой установленной ревизией.
• Решение: Используйте элемент ITEM для установки строк соединения во время выполнения, запишите код в классе Installer, чтобы изменить App.Config во время установки, и используйте параметры приложения по умолчанию, если пользовательский параметр не найден.

Answer 5

Будет ли конец света, если вы сохраните несколько позиций окна и список самых последних использованных элементов в реестре Windows? Пока у меня все нормально.

HKEY-CURRENT-USER - отличное место для хранения простых пользовательских данных в небольших количествах. Вот для чего это. Кажется глупым не использовать его по назначению только потому, что другие злоупотребили им.

Answer 6

Реестр чтения и записи являются потокобезопасными, а файлы - нет. Так что это зависит от того, является ли ваша программа однопоточной.

Answer 7

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

Answer 8

Немного не по теме, но, поскольку я вижу людей, обеспокоенных переносимостью, лучший подход, который я когда-либо использовал, это класс Qt QSettings. Он абстрагирует хранилище настроек (реестр в Windows, файл настроек XML в Mac OS и файлы Ini в Unix). Как клиент этого класса, мне не нужно тратить время на размышления о реестре или о чем-то еще, просто Just Works (tm).

http://doc.trolltech.com/4.4/qsettings.html#details

Answer 9

Если вы разрабатываете новое приложение и заботитесь о переносимости, вы должны НИКОГДА хранить данные в реестре Windows, поскольку другие ОС не имеют (windows) реестра (обратите внимание - это может быть очевидно, но часто упускается из виду).

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

Answer 10

(поздно к обсуждению, но) Краткий ответ: групповая политика.

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

Существуют инструменты для создания пользовательских шаблонов ADMX, которые могут сопоставлять настройки ваших компонентов с расположениями реестра и предоставлять администратору общий интерфейс для реализации политик, которые он должен применять, показывая им только те параметры, которые имеют смысл применять. вот так.