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

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

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

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

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

политика Microsoft:

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

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

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

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

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

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

• проблема: приложения, необходимые настраиваемые параметры.
• решение: хранить настройки в файле (WIN.INI) в папке Windows - используйте заголовки разделов для группировки данных (Win3.0).
• проблема: выиграть.INI файл стал слишком большим (и получил грязный.)
• решение: хранить настройки в INI-файлах в той же папке, что и приложение (Win3.1).
• проблема: нужны пользовательские настройки.
• решение: хранить пользовательские настройки в пользовательских INI-файлах в каталоге окна пользователя (Win3. 11) или в пользовательских разделах INI-файла приложения.
• проблема: безопасность-некоторые настройки приложения должны быть доступны только для чтения.
• решение: реестр с безопасностью, а также конкретного пользователя и машины-широкий секций (с Win95).
• проблема: реестр стал слишком большим.
• решение: пользовательский реестр перемещен в user.dat в собственной папке "данные приложения" пользователя и загружается только при входе в систему (WinNT).
• проблема: в больших корпоративных средах вы входите на несколько машин и должны настроить каждый из них.
• решение: различать локальные (локальные настройки) и перемещаемые (данные приложения) профили (Относится к).
• проблема: не удается xcopy развернуть или переместить приложения, как и остальные. Net.
• решение: приложение.Конфигурационный XML-файл в той же папке, что и приложение -, легко читается, легко манипулируется, легко перемещается, может отслеживать изменения (. Net1).
• проблема: по-прежнему необходимо хранить пользовательские данные аналогичным образом (т. е. xcopy deploy).
• решение: пользователей.Конфигурационный XML-файл в локальной или перемещаемой папке пользователя и строго типизированный (. Net2).
• проблема: конфигурационные файлы чувствительны к регистру (не интуитивно понятны для людей), требуют очень конкретных открытых/закрытых "тегов", строки подключения не могут быть установлены во время выполнения, проекты установки не могут писать настройки (так же легко, как реестр), не могут легко определить пользователя.файл конфигурации и пользовательские настройки выдуваются с каждой новой установленной версией.
• решение: используйте элемент элемента для установки строк подключения во время выполнения, напишите код в классе установщика, чтобы изменить приложение.Конфигурация во время установите и используйте параметры приложения по умолчанию, если пользовательская настройка не найдена.

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

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

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

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

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

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

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

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

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

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

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

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

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

вот 2 примера, которые показывают, как использовать proerties проекта, чтобы сделать это.

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

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

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

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

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

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

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

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

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