Как разработчик, инструменты, которые хранят конфигурацию/параметры в реестре, являются бичем моей жизни. Я не могу легко отслеживать изменения этих параметров, не могу легко переносить их с машины на машину, и все это заставляет меня очень жаждать добрые старые .INI файлы...
При написании моих собственных приложений, что - если что угодно - я должен выбрать для размещения в реестре, а не в старомодных файлах конфигурации и почему?
Идя как с точки зрения пользователя, так и с точки зрения программистов, я должен сказать, что действительно действительно не очень важно использовать что-то в реестре, если это не что-то вроде ассоциаций файлов или конкретных машин.
Я пришел из школы мысли, в которой говорится, что программа должна быть запущена из любого места, где она установлена, что установка должна полностью перемещаться внутри машины или даже на другую машину и не влиять на ее работу.
Любые настраиваемые параметры или требуемые dll и т.д., если они не являются совместно используемыми, должны находиться в подкаталоге каталога установки, чтобы вся установка была легко перемещена.
Я использую много меньших утилит, таких как программы, поэтому, если он не может быть установлен на USB-накопителе и подключен к другой машине и просто запускается, то это не для меня.
Политика Microsoft:
Реестр зависит от машины. Мне это никогда не нравилось, потому что он медлил, и почти невозможно найти то, что вам нужно. Вот почему мне нравятся простые ini или другие файлы настроек. Вы знаете, где они находятся (папка приложения или папка пользователя), поэтому они легко переносятся и читаются человеком.
Когда - вы вынуждены из-за устаревшей интеграции или потому, что ваш системный администратор говорит: "Это так" или потому, что вы разрабатываете более старый язык, что затрудняет использование XML.
Почему - прежде всего потому, что реестр не так переносим, как копирование файла конфигурации, который сидит рядом с приложением (и называется почти таким же).
Если вы используете .Net2 +, у вас есть файлы App.Config и User.Config, и вам не нужно регистрировать DLL в реестре, поэтому держитесь подальше от него.
У конфигурационных файлов есть свои проблемы (см. ниже), но они могут быть закодированы и вы можете изменить свою архитектуру.
Будет ли мир заканчиваться, если вы сохраните несколько позиций окна и список последних используемых элементов в реестре Windows? Это работало хорошо для меня до сих пор.
HKEY-CURRENT-USER - отличное место для хранения тривиальных пользовательских данных в небольших количествах. Это для чего. Кажется глупым не использовать по прямому назначению только потому, что другие злоупотребляют им.
Настройки, которые вы хотите иметь в профиле перемещаемого пользователя, должны, вероятно, попадать в реестр, если вы на самом деле не хотите приложить усилия для поиска папки данных приложения пользователя вручную.: -)
Чтение и запись в реестре являются потокобезопасными, но файлов нет. Таким образом, это зависит от того, была ли ваша программа ничейной.
Если вы разрабатываете новое приложение и заботитесь о переносимости, вы должны НИКОГДА хранить данные в реестре Windows, так как у другой ОС нет реестра (windows) (примечание duh - это может быть очевидно но часто упускается из виду).
Если вы только разрабатываете платформы Win... старайтесь избегать их как можно больше. Файлы конфигурации (возможно, зашифрованные) являются лучшим решением. Там нет выгоды в хранении данных в реестре - (изолированное хранилище - гораздо лучшее решение, например, если вы используете .NET).
Немного не по теме, но поскольку я вижу людей, обеспокоенных переносимостью, лучшим подходом, который я когда-либо использовал, является класс Qt QSettings. Он абстрагирует хранение настроек (реестр в Windows, файл предпочтений XML в Mac OS и Ini файлы в Unix). Как клиент класса, мне не нужно тратить мозговой цикл на вопрос о реестре или что-то еще, это Just Works (tm).
Обычно, если вы не ставите настройки в реестр, вы используете его в основном для получения текущих настроек Windows, изменения ассоциаций файлов и т.д.
Теперь, если вам нужно определить, установлено ли ваше программное обеспечение, вы можете сделать минимальную запись в реестре, это местоположение, которое вы можете найти в любой конфигурации. Или найдите папку с заданным именем в Application Data.
Если я посмотрю папку "Мои документы и настройки", я вижу много программного обеспечения, использующего нотацию Unix для установки папок: .p4qt .sqlworkbench .squirrel-SQL .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (и т.д.)
и в Application Data - различные папки с именами редакторов или именами программ. Похоже, что это текущая тенденция, по крайней мере, среди переносных приложений...
WinMerge использует несколько иной подход, сохраняя данные в реестре, но предлагая импорт и экспорт параметров в диалоговом окне конфигурации.
Лично я использовал реестр для хранения путей установки для использования скриптами (un). Я не уверен, что это единственный возможный вариант, но он казался разумным решением. Это было для приложения, которое, конечно, использовалось исключительно для Windows.
В .NET там действительно НЕ нужна.
Вот два примера, которые показывают, как использовать Project proerties для этого.
Эти примеры делают это с помощью Windows Project Project Properties, но то же самое можно сделать и с помощью приложения.
Подробнее здесь:
(поздно к обсуждению, но). Короткий ответ: групповая политика.
Если ИТ-отдел вашего клиента хочет установить параметры, связанные с Windows, или компоненты (или компоненты), которые вы пишете или добавляете, например скорость ссылки или настраиваемое сообщение об ошибке, или сервер базы данных для подключения к этому по-прежнему обычно выполняется с помощью групповой политики, что делает ее окончательным проявлением как настройки, хранящиеся в реестре. Такие политики применяются с момента запуска Windows или входа пользователя в систему.
Существуют инструменты для создания пользовательских шаблонов ADMX, которые могут сопоставлять настройки ваших компонентов в местах реестра и предоставлять администратору общий интерфейс для обеспечения соблюдения политиками (политиками), которые ему необходимо применять, показывая им только те параметры, которые имеют смысл для обеспечения соблюдения таким образом.
Я считаю, что реестр Windows был хорошей идеей, но из-за большого злоупотребления со стороны разработчиков приложений и стандартных политик, которые не поощрялись/не утверждались Microsoft, превратились в неуправляемого зверя. Я ненавижу использовать его по причинам, о которых вы упомянули, однако есть некоторые случаи, когда имеет смысл использовать его: