How to deal with Windows .NET configuration files

configurationwindowsxml

We use the normal app.config file for the configuration of the application. Although it works for now it has some pretty significant drawbacks:

  • Upgrading an application with a modified app.config is hard. Either it overwrites the existing configuration file or the upgraded app.config isn't installed at all.
  • An error in app.config often renders the entire configuration invalid.
  • The files are read-only and cannot be altered from the application itself.

To overcome these issues I am considering some alternative options.

Custom XML document transformation

An alternative would be to revert back to a custom XML file to prevent these drawbacks. I think of a solution that uses XML document transformation.

The installer will install the default configuration file default.xml and is read-only. It shall never be modified, because it is overwritten during an upgrade. It contains all the default settings and should be sufficient to start the application.

Modifications can be done in the custom-xxx.xml files that are processed in alphabetic order. The modifications are done using the XDT syntax as described here.

The resulting file will be written to configuration.xml that is actually been used. The configuration.xml file should never be directly altered, because it will be overwritten when the application is started again.

I think this approach will have some advantages:

  • The default configuration can be updated during an application upgrade.
  • Local configuration changes can be applied and will be persisted during upgrades.
  • If transformation cannot be applied (syntax error) then the file is skipped, but the default configuration can always be read.

There are some disadvantages too:

  • XDT is not trivial for most users and error-prone.
  • Modifying the configuration from within the application is difficult, because you should write an XDT file.
  • Not all settings can be done outside the app.config, because the .NET framework looks for certain settings in this file.

Custom.xml only

The application has default settings specified in code. These settings can be overriden by the application by using a custom.xml file. This has some advantages:

  • Defaults are specified in code, so will be upgraded automatically when the application is updated.
  • Local configuration changes can be applied and will be persisted during upgrades.
  • If the custom.xml contains errors, then this file is skipped and the default settings can still be used.
  • Relatively easy to create a GUI to modify the settings and only write the non-default settings.

There are some disadvantages too:

  • There is no default.xml, so not all options are clearly visible in the XML file.
  • When the default configuration contains a list, then there is no way to remove items from the list in the custom.xml. Configurations should be modelled in such a way that these circumstances can be handled.

Wrap-up

There are some different scenarios to deal with configuration files. I would like to know how you deal with configurations in situations where the configuration files need to be customized and you want to maintain automatic upgrade scenarios.

Best Answer

I think part of the issues you're facing is in the premise:

Upgrading an application with a modified app.config is hard. Either it overwrites the existing configuration file or the upgraded app.config isn't installed at all.

Don't do that, basically. Configuration is a software artefact, and it should be versioned and go through the same lifecycle as any other artefact, subject to change control and whatever other safeguards your team implements for software artefacts.

I suppose realistically, in a production environment you are likely to have hacks made to the application config to fix problems in an emergency. Ideally the immediate consequence of having to do that would be a properly-managed change that would be deployed to production formally as soon as humanly possible. Therefore a scheduled upgrade would already have this change, and regression shouldn't be a problem.

Criticising the premise probably doesn't provide an adequate answer, so could you expand your question to provide an example of the kind of settings you find to be problematic?

Related Topic