With the new version 8.1 of Sitecore we get a some really nice new features that’s been talked about a lot over the last few weeks. In this post I’d like to highlight one of the minor changes that I think is well worth spreading as well, since it makes life a bit easier for us developers.
The web.config file in a default Sitecore solution is really big and over the past years it has actually grown close to its maximum of 250kB file size. Most configuration in Sitecore can also be patched, but things outside the <sitecore> element cannot be patched as easily. With almost all solutions we need to do at least small changes to the web.config outside the <sitecore> scope, so that means we’ll have to include the web.config in our source code repositories.
You probably already know that having a clear strategy of dividing configs is key to make a solution easier to maintain. Your changes to the config should be clearly separated from the default config that Sitecore provides, so that you can let Sitecore maintain the default config as patches and updates are applied to the solution. 3rd party modules (should) also have their separate config and you should keep yours separate as well.
So the huge web.config file isn’t very elegant and can of course cause some trouble when upgrading Sitecore etc, since we typically have to include it in our code repositories. We want to keep it as small as possible. The first thing I’ve always done with every new instance of Sitecore, is to extract the majority of the web.config into a stand alone Sitecore.config file that I place in the App_Config folder and reference it in the sitecore section. This reduces the ~245kB file to ~25kB on a Sitecore 8.0 instance. I’ve been doing this for years.
So it was really about time Sitecore did something about this, and I was really happy to find that in 8.1, Sitecore have done this in the exact same way. Yes! In addition, Sitecore has also moved the log4net section from web.config into the Sitecore.config, so now we can patch the log4net config as well. Nice!
At last, I’d like to send a little message to Sitecore support: Please don’t ask us to do modifications in the config files. Tell us to patch it with a separate config file instead. I believe you’re working on this already, since it seems like you’ve improved on this over the last year, but I sometime still get the suggestion to modify a config file. I would never go on and actually do that myself, but others may do. Embrace good config structure and patch it instead.
Let’s keep config files well structured and maintainable.
Hi Mikael,
Have you tried to deploy the solution to Azure using Sitecore Azure Module 8.0.
Because while deploying it replaces sitecore.config reference in web.config to entire content which causing big web config size.
Do you know any way to change and deploy this sitecore website without this transformation?
Hi Ankita,
Sorry I have tried 8.0 nor 8.1 in Azure yet.
// Mikael
Hi Mikael,
A little message from Sitecore Support: when we ask to modify the config file we actually mean create a separate include file that performs that modification 😉
Cheers, Alen.
Hi Alen,
That’s good to hear! And I do get more and more suggestions to patch the config instead of modifying existing files. My point was that less experienced issuers may not understand that modifying existing files is not a good idea.
Cheers!
We are trying to get better in this aspect, but it depends on the skills/qualification of specific engineer and on the fact how much overloaded he or she is :). My patches are always live in git repos
https://bitbucket.org/sitecoresupport/sitecore.support.432985
https://github.com/SitecoreSupport/Sitecore.Support.433957
etc.
In fact, writing include files must be the first skill Sitecore engineer should have, and it is a pity if our training courses do not include that.
@Alen – Now that the whole node has been moved into its own file, and that the node has been moved inside can I move in its own separate config file using something like ? My testing shows that this is not possible. And the node cannot be moved out of anymore.
If so, how can I manage different appenders on different servers / environments?
@Francesco, I am not sure that understand your question. It is not important where node is defined: inside the web.config file or in a separate App_Config\Sitecore.config – the developer must not even touch that file (I’d recommend to mark all stock App_Config files as read-only) as it will make upgrade procedure more difficult. If you need to change anything just created App_Config\Include\zzz folder and place your include file there.
If you are talking about environment-specific configuration using MSBuild profiles (like DEBUG and RELEASE) then you cannot use them any longer, and it is good as this approach was horrible. Please take a look at my project here – it is designed to provide alternative and better way: https://github.com/Sitecore/Sitecore-Configuration-Roles