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

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

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

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

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

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

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

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

Политика Microsoft:

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

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

Когда - вы вынуждены сделать это из-за устаревшей интеграции или из-за того, что системный администратор вашего клиента сказал «так и должно быть», или из-за того, что вы разрабатываете на более старом языке, что затрудняет использование 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 в папке «Application Data» пользователя и загружается только при входе в систему (WinNT).
• Проблема: в крупных корпоративных средах вы входите на несколько машин и должны настраивать КАЖДУЮ.
• Решение: различать локальный (локальные настройки) и перемещаемый (данные приложения) профили (WinXP).
• Проблема: невозможно xcopy развернуть или переместить приложения, как остальную часть .Net.
• Решение: XML-файл APP.CONFIG находится в той же папке, что и приложение - легко читается, легко манипулируется, легко перемещается, может отслеживать изменения (.Net1).
• Проблема: по-прежнему необходимо хранить пользовательские данные аналогичным образом (например, xcopy deploy).
• Решение: XML-файл USER.CONFIG в локальной или перемещаемой папке пользователя и строго типизированный (.Net2).
• Проблема: файлы CONFIG чувствительны к регистру (не интуитивно понятны для людей), требуют очень специфических «тегов» открытия / закрытия, строки подключения не могут быть установлены во время выполнения, проекты установки не могут записывать настройки (так же легко, как реестр), не могут легко определить Файл user.config и пользовательские настройки удаляются с каждой новой установленной версией.
• Решение: используйте элемент ITEM для установки строк подключения во время выполнения, напишите код в классе установщика, чтобы изменить App.Config во время установки, и используйте настройки приложения по умолчанию, если пользовательский параметр не найден.

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

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

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

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

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

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

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

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

Обычно, если вы не помещаете настройки в реестр, вы используете его в основном для получения текущих настроек Windows, изменения ассоциаций файлов и т. Д.
Теперь, если вам нужно определить, установлено ли уже ваше программное обеспечение, вы можете сделать минимальную запись в реестре. , это место вы можете найти в любом файле config. Или найдите папку с заданным именем в Application Data.

Если я посмотрю на свою папку Document and Settings, я вижу множество программ, использующих точечную нотацию Unix для настройки папок: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (и т. д.)

а в Application Data - различные папки с названиями редакторов или программ. Похоже, это текущая тенденция, по крайней мере, среди переносимых приложений ...
WinMerge использует несколько иной подход, храня данные в реестре, но предлагая опции импорта и экспорта в диалоговом окне конфигурации.

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

В .NET действительно нет необходимости.

Вот 2 примера, которые показывают, как использовать свойства Project для этого.

Эти примеры делают это с помощью свойств проекта пользователя Windows, но то же самое может / может быть сделано и с помощью приложения.

Подробнее здесь:

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE

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

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

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

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

• Оставление следов вашего приложения после того, как ваше приложение было удалено (например, запомнить настройки пользователя на случай, если приложение будет установлено снова)
• Совместное использование настроек конфигурации между различными приложениями - компоненты