типы - файл реестра windows 7




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

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

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

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

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

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


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

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


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

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


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

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

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

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


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

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


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

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

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


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

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






registry