Split application-specific and customer-specific web.config parts

Question

We have a web application running on-premise at a variety of customers. The web.config contains lots of

1. stuff which is "part of our application" (such as most of the <system.web> and <system.webServer> blocks) and
2. stuff which needs to be customized (connection strings, app settings, and various custom tags).

During updates, part 1 should be replaced and part 2 should be left as it is. Ideally, I'd have a web.app.config and a web.custom.config, so I can replace only the first one. Of course, IIS would need to magically "merge" those at run time, which it does not do.

I found the following approaches:

• Put the custom stuff in external files, i.e. <appSettings configSource="appSettings.config"/>.

  I cannot use that, because it can only be used for complete sections. But, for example, the aspnet:MaxHttpCollectionKeys setting is a value that should be controlled by the application, whereas other app settings values should be customizable.

• Parameterization or Web.Config Transformation.

  I cannot use that, because our customers have various versions of our application installed. Thus, I need to replace the application-specific parts of web.config rather than transforming individual tags. In addition, I'd like to avoid adding msdeploy to our deployment process (xcopy plus some scripts to create the IIS apps and configure them work great at the moment). Oh, and I'd still have one big web.config with application-specific and customer-specific stuff meshed together.

Is there some elegant solution that I've missed?

Answer 1

It's true that configSource is used for complete sections, but appSettings has a special attribute called file which can be used to reference a file to be 'merged' into the appSettings list. See https://msdn.microsoft.com/en-AU/library/ms228154(v=vs.85).aspx for more details. I've used extensively to merge in an appSettings.config file with environment specific values - either local dev values (as contained in the repo) or a file that is dumped onto the server with environment specific settings. Helpful when promoting a build artifact through qa, uat, prod environments etc. For you, that file could contain your customer specific values and would not change when you deploy updates.

An alternative approach would be to refactor your customer specific configuration into a Custom Configuration Section. As well as giving you typed access to the configuration values, you can load it from a section in the web.config, load it from a section in the web.config that references another file via configSource, or you can load it directly from a separate file.

You can then leave your application configuration in the appSettings, or move it into a separate custom configuration section.