What do we do about config file bloat?

It is always nice to see our dedicated partners give input / comments / criticism that confirms our internal discussions and decisions. See Fredrik Haglunds blog post about config file bloat here http://blog.fredrikhaglund.se/blog/2009/10/21/i-do-not-like-the-trend-for-episerver-webconfig/  I will now do an EPiServer first (*drum roll*) – I will post the verbatim guideline on dealing with configuration settings. This guideline was approved by the Product Integration Group on September 15.

Do not expect that this will have a huge impact on EPiServer CMS 6 since it is now in the final stages of development, but it will definitely affect our future development efforts.

Large configuration files

Basically every system that has externalized its configuration settings will at some point reach a stage where the amount of configuration is simply overwhelming and start to cause more issues than the configurability was originally intended to solve. I think we are getting close to that point with EPiServer.

There are many reasons that this has happened. Just to name a few: we integrate with the ASP.NET settings and a lot of config overhead is caused by this integration, new features seems to add new configuration needs, all possible config settings are entered in the configuration file regardless if they are at the default setting or not.

Some mitigating factors exists, such as splitting web.config into multiple configuration files to reduce the visual clutter etc, but we are still faced with a real problem.

What should we do?

Limit what you put into the configuration files. Basically everything (yes, there are exceptions) should have sensible defaults and the only things that should appear in config files are exceptions to the default settings. This makes relevant changes easy to spot and will help both customers and our support to spot issues.

General guidelines

1. Does this feature need configuration at all?
   Try to write code that is auto-configuring. This may come into conflict with limiting the amount of external dependencies, but if possible - avoid configuration requirements completely.
2. Configuration should be optional.
   Yes, there are exceptions to this guideline as well. For example if you add functionality that needs configuration (see first guideline) to an existing feature that has an existing config section then you would most likely want to add new config settings with default values to the config file in order to be consistent.
   If no config settings exists then sensible and secure defaults should be used. Always secure by default.
3. Configuration should be overrideable in code (both internal and external).
   The API:s that are used to inject the settings from configuration files should be public. This for example requires providers based on the Framework class System.Configuration.ProviderBase to expose public ways of configuring the provider outside of the Initialize(string name, NameValueCollection config) method. Your code should be written to accept configuration changes after Initialize has been called.

These guidelines will introduce new challenges but ultimately I think we and our customers will benefit from it. Just adding configuration capabilities "to increase flexibility" is not always a good thing, increased flexibility = increased complexity. Always having public configuration API:s will also help in unit and integration testing scenarios.