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


126

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

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


Сейчас я работаю с устаревшим приложением, которое хранит информацию в реестре (приложение .NET), и это сводит меня с ума.
Джордж Стокер,

Ответы:


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

16
Unix: конфигурация хранится в $ HOME / .your-app Там, решена за одну итерацию.
Леонель

33
Решение для Unix тоже далеко не идеальное: $ HOME переполнен точечными файлами, и вы понятия не имеете, что большинство из них делает.
grep

2
@Leonel XDG фактически требует, чтобы вы помещали свои файлы конфигурации внутрь $HOME/.config/your-app/, решение, созданное для решения проблемы с объектами @grep. И, что удивительно, современный Linux (и любой в * BSD, достаточно сумасшедший, чтобы использовать GNOME) также имеет реестр в gconfпакете. FOSS порождает выбор, это точно;)
new123456

1
@grep, Re " не знаю, что большинство из них делает ", почему бы и нет? К тому же раздувание вряд ли сравнимо с раздутием Windows.
Pacerier 07

16

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

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

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

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


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

@Cheeso, Решение - чтобы у каждого пользователя была копия исполняемого файла. Для экономии места не настоящая копия, а просто поддельная копия (указатель).
Pacerier 07

12

Политика Microsoft:

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

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


1
Можете ли вы предоставить исходную ссылку на документ, в котором изложена эта политика Microsoft? И когда вы говорите «политика», вы имеете в виду, что это то, что делает Microsoft, или вы имеете в виду, что это то, что Microsoft рекомендует разработчикам, которые создают приложения для Windows?
Cheeso

1
ps: Раймонд Чен из Microsoft заявил, что файлы INI устарели в пользу реестра, и объясняет, почему. blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx Он также заявляет, что файлы XML имеют многие из тех же недостатков, что и файлы ini.
Cheeso

8
Файлы настроек XML = файлы INI, которые сложнее анализировать,
Роберт Фрейзер,

3
@Fraser, если вы думаете, что разбирать XML сложно, значит, вы не в том бизнесе.
SnakeDoc

@SnakeDoc, сложнее не значит сложнее. Это просто означает более медленный синтаксический анализ и задержку.
Pacerier

12

Когда - вы вынуждены сделать это из-за устаревшей интеграции или из-за того, что системный администратор вашего клиента сказал «так и должно быть», или из-за того, что вы разрабатываете на более старом языке, что затрудняет использование 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 во время установки, и используйте настройки приложения по умолчанию, если пользовательский параметр не найден.

Это гораздо более полный ответ, чем утвержденный. Спасибо @AndrewD.
ротман

8

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

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


и он отлично себя портит ... это плюс. Меньше работы для пользователя ...
SnakeDoc

4

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


4

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


2

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

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


Отчасти это правда. В Mono реализовано пространство имен Microsoft.win32 для реестров - за исключением того, что оно хранится в файле в ~ / .mono / Registry в xml-файле и обрабатывается прозрачно. Теперь, если бы вы могли включить обработку xml для любого приложения, независимо от платформы ...
Роберт П.,

Примечание: доступно только в том случае, если вы пишете приложение .NET / Mono.
Роберт П.

Реестр дает преимущество: данные более доступны в многопоточном приложении. Что еще более важно, он позволяет разделять данные конфигурации, которые зависят от машины и пользователя. Ваше приложение не должно знать, кто вошел в систему, когда оно обращается к HKEY_CURRENT_USER. Впрочем, насчет портативности вы правы.
Джеймс

2

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

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


Похоже, URL-адрес больше не работает. Ссылка на обновление должна быть qt-project.org/doc/qt-5/QSettings.html#details
Eineki

0

Обычно, если вы не помещаете настройки в реестр, вы используете его в основном для получения текущих настроек 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 использует несколько иной подход, храня данные в реестре, но предлагая опции импорта и экспорта в диалоговом окне конфигурации.


Точечная нотация Unix, вероятно, вызвана тем, что все эти примеры относятся к портированным проектам с открытым исходным кодом, а не потому, что это лучшая практика для разработки под Windows.
Джеймс

На самом деле, я не сказал, что это «лучшая практика», но обычная практика ... :) Папки в данных приложения / являются / лучшими практиками, особенно для больших данных, но также потому, что их легче создавать резервные копии.
PhiLho

0

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


0

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

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

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

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

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

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


0

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

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

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


-1

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

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

5
Я не согласен с вами относительно вашего первого пункта: «[l] отслеживание вашего приложения после того, как ваше приложение было удалено». Я бы предпочел, если я скажу «удалите себя из моей системы», чтобы ваше приложение полностью соответствовало требованиям. Я полагаю, было бы иначе, если бы вы спрашивали пользователя, можно ли оставить что-то позади, но даже тогда я бы, вероятно, хотел, чтобы это был сохраненный файл конфигурации. Несмотря на лицензирование и т. Д., Если вы продаете свой компьютер и покупаете новый, разве вы не предпочли бы иметь файл настроек, который вы можете загрузить при новой установке, а не что-то, связанное с компьютером, который вы продаете?
AgentConundrum,

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

2
Думаю, мы нашли здесь автора вредоносного ПО. Никогда не оставляйте мусор из своей программы в чьей-либо системе, если вас попросят удалить ее. По крайней мере, спросите их, хотят ли они запомнить настройки и т. Д. Никогда не делайте этого просто так. Что делать, если вы храните лицензионный ключ, а я продам свой компьютер? Что, если ваша программа вызывала проблемы на моем компьютере, и я попытался удалить ее, чтобы исправить это? Что ж, остатки вашего реестра могут доставить мне много проблем. Просто не делай этого. Только не надо.
SnakeDoc
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.