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

Answer 1

As Daniel indicated, storing configuration data in the registry gives you the option to use Admin Templates. That is, you can define an Admin Template, use it in a Group Policy and administer the configuration of your application network-wide. Depending on the nature of the application, this can be a big boon.

Answer 2

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.

Answer 3

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.

Answer 4

The existing answers cover a lot of ground but I thought I would mention one other point.

I use the registry to store system-wide settings. That is, when 2 or more programs need the exact same setting. In other words, a setting shared by several programs.

In all other cases I use a local config file that sits either in the same path as the executable or one level down (in a Configuration directory). The reasons are already covered in other answers (portable, can be edited with a text editor etc).

Why put system-wide settings into the registry? Well, I found that if a setting is shared but you use local config files you end up duplicating settings. This may mean you end up needing to change a setting in multiple places.

For example, say Program A and Program B both point to the same database. You can have a "system-wide" registry setting for the connection string. If you want to point to a different database, you can change the connection string in one place, and both programs will now run against the other database.

Note - there is no point in using the registry in this way if two or more programs don't need to use the same values. Such as, Program A and Program B both needing a database connection string that may be the same, but not always. For example, I want Program B to now use a test database but Program A should carry on using a production database.

With the above example, you could have some local configuration override system-wide settings but it may start getting overly complicated for simple tasks.

Answer 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#.

Answer 6

Other disadvantage of using the registry is that it is a pain if you are working in a mixed environment of 32 and 64 bit applications, as the system call for accessing the registry will randomly(*) add \Wow6432Node\ to your registry path making you crazy while debugging.

(*of course not randomly, but very easy to get lost)