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
Optimizely finally releases new and improved list properties!

For years, the Generic PropertyList has been widely used, despite it being unsupported. Today a better option is released!

Tomas Hensrud Gulla | Mar 28, 2023 | Syndicated blog

Official List property support

Introduction Until now users were able to store list properties in three ways: Store simple types (int, string, DateTime, double) as native...

Bartosz Sekula | Mar 28, 2023

New dashboard implemented in CMS UI 12.18.0

As part of the CMS UI 12.18.0 release , a new dashboard has been added as a ‘one stop shop’ to enable editors to access all of their content items,...

Matthew Slim | Mar 28, 2023

How to Merge Anonymous Carts When a Customer Logs In with Optimizely Commerce 14

In e-commerce, it is common for users to browse a site anonymously, adding items to their cart without creating an account. Later, when the user...

Francisco Quintanilla | Mar 27, 2023

How to Write an xUnit Test to Verify Unique Content Type Guids in Content Management

When developing an Optimizely CMS solution, it is important to ensure that each content type has a unique GUID. If two or more content types share...

Minesh Shah (Netcel) | Mar 27, 2023

Extend TinyMCE in Optimizely CMS 12

Since technologies are upgraded to newer versions the ways to extend or override the out-of-the-box functionality are also changed a little bit so...

Ravindra S. Rathore | Mar 27, 2023 | Syndicated blog