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

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