What is the best practice for managing Web.config changes in a solution?

Question

To my knowledge, it is considered a best practice not to include any of Sitecore's out-of-the-box configuration files into Visual Studio web projects. The reason being, if you handle all configuration changes as custom patch files (rather than directly modifying the default configuration), updating Sitecore to a newer version will be much easier.

But what should I do with Web.config changes? This file cannot be patched by Sitecore configs. At the same time, Sitecore's Web.config already has a lot of configuration, so I cannot replace it with my own.

I currently need to add a new assembly binding redirect. Do I just include the Web.config that's included with Sitecore into my web project? Or is there any other way?

Answer 1

Pre Sitecore 8.1 (which splits out the Sitecore node into /App_Config/Sitecore.config) - I generally create my own Sitecore.config and patch that into the web.config in the same way as the connection strings is done.

Then yes, I just have the resulting web.config from my Sitecore installation in the web project. With debug transforms for local development.

So assembly bindings would be added in there.

With 8.1+ the removal of the Sitecore node is done for you, so just add the web.config from the installation to your web project and use that.

Answer 2

By far the most common solution to this is to use Web.config transforms built into Visual Studio and MSBUILD. The following MSDN articles should give a good jumping point:

• https://msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx
• https://msdn.microsoft.com/en-us/library/dd465326(v=vs.110).aspx

You may also want to consider SlowCheetah for transforming other configuration files besides Web.config, which isn't supported out of the box with VS or MSBUILD.

• https://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5

For your specific issue with adding binding redirects, there's really no reason to include those in a patch file as those are extremely unlikely to change between environments (e.g. staging and production). Using Web.config transforms along with Richard Seal's answer, you'll most likely want to just add the binding redirects directly into your Web.config.

Answer 3

We create a separate project for configs. Like @RichardSeal and others, we always split Sitecore.config out, and appSettings, log4net and urlRewrite too. This has the advantage of making changes to various aspects easier to diff/track through source control.

SlowCheetah allows for altering values based on your build configuration or publish profile, but you can use the same idea and a bit of msbuild magic to also alter configuration per dev machine this way. An msbuild task or post-build step copies the configuration into the target project/location.

You can add code to the project that is related to the configs as well to make it easier to find (many people map settings to a singleton object for example).

We also take all the subdirectory configs from include and put them into a folder called 01-Base. Then any platform wide overrides go into 02-Platform, while per-environment overrides for Dev/QA/Live etc go into 03-Environment. This allows us to easily control the load order, and it makes it easy to locate settings and patch files.

In your specific case, adding binding redirects or other necessities into web.config or assembly-specific configs is a non-issue.

Answer 4

I include the web.config from Sitecore in the project because some things can't be included otherwise (if someone can show me how, that would be great though). What I do try to do is creating separate files as much as possible. For example: when using the IIS Rewrite module you can refer to an external file so only the reference is in the web.config.

Answer 5

We are using SlowCheetah for adjusting config files per target environment. This is helpful for connection string, solr indexes, etc. One additional note on using SlowCheetah that we initially struggled with--if your Visual Studio solution is over top of the IIS site, then all *.config file in App_Config\Include will get included when Sitecore starts, causing errors when you try to start your site. Sitecore ignores hidden files, so you must mark each of your transform configs as hidden in the file system (which doesn't seem to affect Visual Studio) to get your local Sitecore instance to run properly.