Registry vs. INI file for storing user configurable application settings

Question

I'm a new Windows programmer and I'm not sure where I should store user configurable application settings. I understand the need to provide a user friendly means for the user to change application settings, like an Edit | Settings form or similar. But where should I store the values after the user hits the Apply button on that form?

What are the pros and cons of storing settings in the Windows registry vs. storing them in a local INI file or config file or similar?

Solution 1

Jeff Atwood has a great article about Windows' registry and why is better to use .INI files instead.

My life would be a heck of a lot easier if per-application settings were stored in a place I could easily see them, manipulate them, and back them up. Like, say... in INI files.

• The registry is a single point of failure. That's why every single registry editing tip you'll ever find starts with a big fat screaming disclaimer about how you can break your computer with regedit.
• The registry is opaque and binary. As much as I dislike the angle bracket tax, at least XML config files are reasonably human-readable, and they allow as many comments as you see fit.
• The registry has to be in sync with the filesystem. Delete an application without "uninstalling" it and you're left with stale registry cruft. Or if an app has a poorly written uninstaller. The filesystem is no longer the statement of record-- it has to be kept in sync with the registry somehow. It's a total violation of the DRY principle.
• The registry is monolithic. Let's say you wanted to move an application to a different path on your machine, or even to a different machine altogether. Good luck extracting the relevant settings for that one particular application from the giant registry tarball. A given application typically has dozens of settings strewn all over the registry.

Solution 2

There's one more advantage to using an INI file over the registry which I haven't seen mentioned: If the user is using some sort of volume/file based encryption, they can get the INI file to be encrypted pretty easily. With the registry it will probably be more problematic.

Solution 3

There's a similar question here that covers some of the pros and cons.

I would suggest not using the registry unless your application absolutely needs it. From my understanding, Microsoft is trying to discourage the use of the registry due to the flexibility of settings files. Also, I wouldn't recommend using .ini files, but instead using some of the built-in functionality to .Net for saving user/app settings.

Solution 4

Use of an ini file, in the same directory as the application, makes it possible to back it up with the application. So after you reload your OS, you simply restore the application directory, and you have your configuration the way you want it.

Solution 5

I agree with Daniel. If it's a large application I think I'd do things in the registry. If it's a small application and you want to have aspects of it user-configurable without making a configuration form, go for a quick INI file.

I usually do the parsing like this (if the format in the .ini file is option = value, 1 per line, comments starting with #):

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();
    }
}

Edit: Sorry, I thought you had specified the language. The implementation above is in C#.

View more solutions

Comments

[Andy White]

I totally agree. The registry just reeks of garbage and rinky-dink apps that you can never completely delete.

[EvilTeach]

Put it in the same directory as the exe. Pull the exe directory from argV[0].

[idbrii]

There's a whole question on this (for c#).

[syplex]

You can't rely on argv[0]. It can be absolute, relative, or completely empty or completely wrong (for example, if a process is launched via exec*). Use GetModuleFileName with a NULL first param instead followed by PathCanonicalize to remove extraneous path elements.

[v.oddou]

you're expected to put your ini in %appdata%.

[v.oddou]

...and then its also not perfect because it can be a symlink. you need to finish that using GetFinalPathNameByHandle.

[Kinjal Dixit]

This is what I wanted to say. If I want to add an extension to chrome or firefox as part of my installation, the way to do that is to add registry entries that chrome/firefox expects to find. This also applies to registering with some app as a plugin/helper etc. Because the other app may not be running at the time any kind of IPC wont work. Also if you search for the app, you don't know if it is the version that is being used or a backup. Registry is the way to go here.

[Ömür Ölmez]

There is "Program Data" folder for "system-wide" shared config files.

[DDS]

Just put 'em in `%APPDATA%\YOURAPP`

[Wolf]

This makes really sense for portable applications, whereas application installed into the %PROGRAMFILES% folder should better use a subfolder in %APPDATA% that is mostly named after (company and) application.

[EvilTeach]

That is lost after a OS reload.