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

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

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

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

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

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

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

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

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

Я бы посоветовал не использовать реестр, если это не нужно вашему приложению. Насколько я понимаю, 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 #.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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