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.


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.

  • This varies by language and OS. In Windows C#, reasonable approaches to storing user settings include: 1. Store configuration in the user profile directory (.config files can be loaded from arbitrary locations, if you still want to use .config). 2. Use a Settings File: Right click your project, click "Add->New Item," and select Settings File. 3. Use registry.
    – Brian
    Commented Nov 21, 2014 at 19:30

3 Answers 3


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?

  • I think you are right. Software configuration should be versioned as well. I know added some lines to my software upgrade procedures that changes the app.config during the upgrade process. It helps to fix my issue. Commented Nov 24, 2014 at 21:25
  • An example is the 'free diskspace checking'. It's a feature that I added just recently and the app.config file contains the number of MB left before it should raise an alert. I would like to have the default value in the app.config, so it can be easily changed (without typos). I now add the line if it's not there using my upgrade script. Commented Nov 24, 2014 at 21:27

In our applications, we only use the app.config to point to the related servers (web, db, license). Any other kind of configuration data is

  • either stored as a local user config file (assumed it is configuration data only important for look-and-feel of the application of the local machine, thus dispensable)

  • or stored in the database (if it is more important configuration data, which has to be backuped)

This means

  • we never have the need for updating / changing the app.config by the installer after first installation, since it never changes its structure

  • we provide a GUI within the application for all kind of configurations, database or local file, whatever is necessary

  • whenever configuration data is extended, the GUI provides meaningful default values, and there is always a button "reset to default" for the related data, or a button "copy from other project", if it is project-related configuration data.

Using this strategy, it actually does not matter for the user or for the customers, how the data is stored internally. Try to avoid the need for the users to edit any XML manually, then your whole question becomes pointless, just choose the format you can process most easily in your program.

  • I do seperate user configuration and software configuration. But sometimes an upgrade requires an update to the software configuration and I am looking for something to deal with that. Commented Nov 24, 2014 at 21:24
  • @RamondeKlein-LePetit: it seems you missed my point. My point is: you can avoid such complicated approaches as you described in your question when you keep your application config (what you call "software configuration") as small as possible, and use a GUI for everything else. And if you really have the need for a complicated application config, why not add a simple GUI tool for the administrator for editing it?
    – Doc Brown
    Commented Nov 24, 2014 at 21:48

Have you thought about breaking up your config file into several files? Look into configsource, which allows you to refer to a separate file for a section in your config.

<pages configSource="pages.config"/>


You can use that to put values that change often into a smaller file, making it easier to maintain.

  • I already did that and it helps a bit, but it doesn't help with upgrading the files and adding things to it. Commented Nov 24, 2014 at 21:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.