Magnus Stråle
Oct 22, 2009
(3 votes)

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

Oct 22, 2009


Sep 21, 2010 10:32 AM

>3.Configuration should be overrideable in code (both internal and external).
I would love that.
/ Anders Hattestad

Joel Abrahamsson
Joel Abrahamsson Sep 21, 2010 10:32 AM

Magnus, you know I think you guys do a great job and all that.

But, in the context of this blog post, it makes me sad to see things like this:

Sep 21, 2010 10:32 AM

I don't like to make excuses, but the Quick Publishing feature has not been touched since early CMS 5. However I have added this to our tech backlog and hope to fix it soon.

Joel Abrahamsson
Joel Abrahamsson Sep 21, 2010 10:32 AM

Ahh, I see. Sorry about bitching about old stuff! I thought it was new as the dashboard has a quick publish gadget. Shows what I know :)

Please login to comment.
Latest blogs
4 tips and tricks for Hangfire on Optimizely CMS

Here are four useful tricks I always apply to any site where I use Hangfire (code included).

Stefan Holm Olsen | Mar 21, 2023 | Syndicated blog

The new LinkItem property in Optimizely CMS, and why it matters

In the past, we have used different tricks to achieve this. Now, the LinkItem property is finally built-in in Optimizely CMS 12!

Tomas Hensrud Gulla | Mar 20, 2023 | Syndicated blog

A day in the life of an Optimizely Developer - Vertical Slicing in CMS12

There is such a vast choice these days in how you can build a website, aside from all of the different programming languages out there, there are...

Graham Carr | Mar 20, 2023

Tag Helpers in CMS 12

Microsoft introduced the TagHelper back in the primordial soup of ASP.NET vNext which became .Net 5, then .NET Core then .Net 5 you know the drill…...

MartinOttosen | Mar 20, 2023