Реестр и файл INI для хранения настраиваемых пользователем параметров приложения

Я новый программист Windows и не уверен, где мне хранить настраиваемые пользователем параметры приложения. Я понимаю необходимость предоставления пользователю удобных средств для изменения настроек приложения, например Edit | Форма настроек или аналогичная. Но где мне хранить значения после того, как пользователь нажмет кнопку «Применить» в этой форме?

Каковы плюсы и минусы хранения настроек в реестре Windows по сравнению с хранением их в локальном файле INI, файле конфигурации или аналогичном?

Ответов (13)

Решение

Плюсы конфигурационного файла:

  1. Легко сделать. Не нужно знать никаких вызовов Windows API. Вам просто нужно знать интерфейс файлового ввода-вывода вашего языка программирования.
  2. Портативный. Если вы переносите свое приложение на другую ОС, вам не нужно менять формат настроек.
  3. Редактируется пользователем. Пользователь может редактировать файл конфигурации вне выполняемой программы.

Плюсы реестра:

  1. Безопасный. Пользователь не может случайно удалить файл конфигурации или повредить данные, если он / она не знает о regedit. И тогда пользователь просто напрашивается на неприятности.
  2. Я не опытный программист Windows, но я уверен, что использование реестра упрощает выполнение других вещей, специфичных для Windows (пользовательские настройки, сетевое администрирование, такое как групповая политика, или что-то еще).

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

Согласно документации для GetPrivateProfileString , вы должны использовать реестр для хранения информации инициализации.

Однако при этом, если вы по-прежнему хотите использовать файлы .ini и использовать стандартные API-интерфейсы профилей ( GetPrivateProfileString, WritePrivateProfileString и т.п.) для доступа к ним, они предоставляют встроенные способы автоматического предоставления «виртуальных файлов .ini», поддерживаемых реестр. Беспроигрышный вариант!

Есть еще одно преимущество использования файла INI над реестром, о котором я не упоминал: если пользователь использует какое-то шифрование на основе тома / файла, он может довольно легко зашифровать файл INI. С реестром наверное проблематичнее будет.

Джефф Этвуд написал отличную статью о реестре Windows и о том, почему лучше использовать файлы .INI.

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

  • Реестр - единственная точка отказа . Вот почему каждый совет по редактированию реестра, который вы когда-либо найдете, начинается с большого жирного кричащего отказа от ответственности о том, как вы можете сломать свой компьютер с помощью regedit.
  • Реестр непрозрачный и двоичный . Как бы мне ни не нравился налог на угловые скобки, по крайней мере файлы конфигурации XML достаточно удобочитаемы, и они допускают столько комментариев, сколько вы сочтете нужным.
  • Реестр должен быть синхронизирован с файловой системой . Удалите приложение, не «деинсталлируя» его, и у вас останется устаревший мусор в реестре. Или если приложение имеет плохо написанный деинсталлятор. Файловая система больше не является записью - ее нужно как-то синхронизировать с реестром. Это полное нарушение принципа DRY.
  • Реестр монолитный . Допустим, вы хотите переместить приложение на другой путь на вашем компьютере или даже на другой компьютер. Удачи в извлечении соответствующих настроек для этого конкретного приложения из гигантского архива реестра. У данного приложения обычно есть десятки настроек, разбросанных по всему реестру.

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

Я использую реестр для хранения общесистемных настроек. То есть, когда 2 или более программ требуют одинаковых настроек. Другими словами, параметр используется несколькими программами.

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

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

Например, предположим, что программа A и программа B указывают на одну и ту же базу данных. У вас может быть "общесистемный" параметр реестра для строки подключения. Если вы хотите указать на другую базу данных, вы можете изменить строку подключения в одном месте, и теперь обе программы будут работать с другой базой данных.

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

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

Другой недостаток использования реестра заключается в том, что это неудобно, если вы работаете в смешанной среде 32- и 64-битных приложений, поскольку системный вызов для доступа к реестру будет случайным образом (*) добавлять \Wow6432Node\ в ваш путь реестра, что сводит вас с ума во время отладки. .

(* конечно не случайно, но заблудиться очень легко)

Устанавливается ли ваше приложение вместе с программой установки или просто «распаковать и запустить»? В первом случае обратите внимание на плюсы и минусы, изложенные здесь. Но для извлечения и запуска реестр, на мой взгляд, не подходит, так как люди ожидают, что для избавления от вашей программы вы сможете просто удалить папку приложения.

Там есть аналогичный вопрос здесь , что охватывает некоторые плюсы и минусы.

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

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

Обычно я выполняю такой синтаксический анализ (если формат файла .ini - option = value, 1 на строку, комментарии начинаются с #):

static void Parse()
{
    StreamReader tr = new StreamReader("config.ini");
    string line;
    Dictionary<string, string> config = new Dictionary<string, string>();

    while ((line = tr.ReadLine()) != null)
    {
        // Allow for comments and empty lines.
        if (line == "" || line.StartsWith("#"))
            continue;

        string[] kvPair = line.Split('=');

        // Format must be option = value.
        if (kvPair.Length != 2)
            continue;

        // If the option already exists, it's overwritten.
        config[kvPair[0].Trim()] = kvPair[1].Trim();
    }
}

Изменить: извините, я думал, что вы указали язык. Вышеупомянутая реализация находится на C#.

Как указал Дэниел, хранение данных конфигурации в реестре дает вам возможность использовать шаблоны администратора. То есть вы можете определить шаблон администратора, использовать его в групповой политике и управлять конфигурацией вашего приложения в масштабе всей сети. В зависимости от характера приложения это может быть большим благом.

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

Есть общее руководство по программированию для Windows - делайте все так, как Microsoft ожидает от вас, и ваша жизнь станет намного проще.

Тем не менее, я вижу апелляцию INI-файла и никого не виню за его рассмотрение.

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

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