Multiple Applications, Shared Settings: Use the registry or XML-based configuration?

Question

My Scenario

I have a class library that is going to be called from multiple separate executable applications. This class library needs to know about an address of a database server (and many other configuration options, auth info, etc) to access. I have a configuration and administration application, separate from the class library, that also needs to know and set these configuration options.

My Question

Is it be common practice to store these user specific configuration options in the Windows registry, or is it preferred to use the typical 'App.config' XML approach for the class library and allow the configuration tool to change and modify it?

I am leaning toward the registry approach, but I know many people have opinions about not using it. What would you do?

Answer 1

I prefer xml configs over registry settings because I can simply make a class and use the xmlSerializer to open and save right into my classes.

Check this topic out for a similar SO question.

Answer 2

In my specific case, these specific config settings made more sense to be stored in the registry. I can't be positive that our users will install the applications to the same locations, and at the very least, I'd have to store the location of the "master" config XML file in the registry so the other applications could locate it.

I simply whipped up a class with an index to read/write configuration settings to the registry like a Hashtable (string ponySetting = myRegistryObject["DefaultPonySetting"]) and called it a day. I reference the main assembly with this class in all the other applications anyways. Huzzah

Answer 3

The best practice is to use XML configuration files in the user's %appdata% directory.

There are a number of reasons for this:

1. Your application is most likely to be installed into Program Files. If the user hasn't granted (or been granted) administrative rights to your application's process, you won't be able to write to the file.
2. I've worked in partially trusted environments where registry access is just simply not an option. The client had completely disabled registry permissions to the .NET Runtime on that server.

3. Your user should always have access to their own %appdata% directory. Here's a sample:

   string configFilePath = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) + "myAppConfig.config";
   ExeConfigurationFileMap map = new ExeConfigurationFileMap();
   map.ExeConfigFilename = configFilePath;
   Configuration cfg = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
   cfg.AppSettings.Settings.Add("mySetting", "myValue!");
   cfg.Save(ConfigurationSaveMode.Modified);
   
   
   // to read the setting back
   
   
   string mySetting = cfg.AppSettings.Settings["mySetting"].Value;
   // at this point, mySetting = "myValue!"
   

Remember to add the System.Configuration v2.0.0.0 reference to your project! The default System.Configuration namespace does not have all of the required classes.

Answer 4

I wouldn't use the registry for sure but for simple application-wide settings I just roll my own XML file in the same location as the EXE and use my own classes to access it. For this sort of thing the setting handling in .NET is way overcomplicated, and it's not even as bad now as it used to be.