I do not like the trend for EPiServer web.config!

October 21, 2009 | 5 comments

Everyone is talking about CoC (Convention over Configuration) and DRY (Don’t Repeat Yourself) today. The idea is to reduce the amount of repetitive, needless configuration and just keep what’s important.

imageHere is a graph with the number of lines in web.config for a clean installation of EPiServer CMS from version 4 to 6 (CTP2). Adding Community, Mail or other product will not make it better.

Complexity is making EPiServer CMS expensive to own

Handling web.config takes time and effort when you have to merge changes between different environments during deployment and each version is adding more and more configuration to your web.config-file.

And it increases the risk or mistakes because important settings disappears in all noise from comments and default settings.

What can be done?

Here are my suggestions and I urge EPiServer to implement the before they release EPiServer CMS 6:

  • Comments: -246 lines. Just moving all comments and example settings to a separate file that is overwritten with the latest version during upgrade.
  • Oracle: -60 lines. Why not a separate sample file for oracle?
  • EPiServer UI-settings. –78  lines. Why not mount user interface folders using IIS virtual folders? Then you could move a lot in location tags to other web.config files!
  • Workflow: –42 lines. Not used by many. Why not put it in the sample file for people to include if they want it or start it with default values.
  • RemoteEvents: –32 lines. WCF Service configuration – Why not have a programmatic or shared database config
  • siteSettings: A line over 1500 characters long. Why not remove the default values and make it shorter?
  • Providers: –8 lines. Skip adding providers that are not used. Just keep the other in the sample file.

Enough whining for today :-)

Bookmark and Share
  1. Martin S.’s avatar

    Martin S. on October 21, 2009 at 17:03

    Spot on, great post and tips to EPiServer. This Web.Config maintenance hell will also be a bit easier with .NET 4 :)

    Reply

  2. Ted Nyberg’s avatar

    Ted Nyberg on October 21, 2009 at 17:44

    I agree in general, and I loved the chart! :)

    I think it’s great to separate the configuration into different .config files (not just connection strings) – it definitely makes versioning and deployment easier!

    Just 2 cents on default values – I don’t think they should be removed for EPiServer-specific configuration elements.

    They may well be left out for standard ASP.NET elements, but EPiServer-specific elements’ default values should be kept so that developers know what the default values are (and also which settings you can change).

    Reply

  3. Henrik Nystrom’s avatar

    Henrik Nystrom on October 22, 2009 at 00:11

    I couldn’t agree with you more, Fredrik.

    Removing all the default values and examples from the production install and ship the public templates with a full web.config with all default values, examples and comments. Then developers can use that to discover and learn about configuration settings as Ted mentions.

    I’m also worried about references to page IDs, page type IDs and other things that is getting added lately. These values changes between environments and deployments and being in an environment where we pass on deployment scripts to a hosting engineer this is a nightmare.

    Always good to read your posts!

    Cheers
    Henrik

    Reply

  4. Mikael Söderström’s avatar

    Mikael Söderström on October 30, 2009 at 13:46

    Why not use the same method as in .NET 4.0? Since there is a new version of the CLR (the first new since .NET 2.0) they had the ability to move all settings to machine.config.

    Wouldn´t it be possible to do the same in EPiServer? Why not just move some of the configuration settings to machine.config? There is a lot of shared properties between all the sites on a single server.

    Reply