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

Question

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

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

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

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

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

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

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

Answer 10

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

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

Тем не менее, я вижу привлекательность файла INI, и я бы не стал никого обвинять в этом.