DRYing Up Shared Web.config Settings

I recently modified some connection strings and settings across multiple ASP.NET web applications in a large solution. It (only) took an hour, but in the process I found multiple incorrect and stale settings. The code violated the DRY principle. The fix involved referencing the common shared settings from a single source instead of repeating them across the solution.

Creating a DRY Config

In my case, I had two SQL connection strings and ~10 app settings that should have been shared. It would be a bug for one project to have a different value for these settings than the other projects in the solution. ASP.NET 5 is a bit more flexible in merging configurations from multiple sources, but I needed to use the traditional Web.config and App.config files.


It turned out to be straightforward to share common appSettings with the following code in my App.config file:

<appSettings file="CommonSettings.config">
  <add key="Value1" value="123" />

All of my common settings are defined in CommonSettings.config and can be referenced by each project in my solution. Any additional values that are only used by a single project are added the normal way within the appSettings element.


Unfortunately, connectionStrings don’t support the file attribute. Instead, I needed to use the configSource attribute. The main difference is that the entire section is defined in the referenced file, i.e. I can’t add a connection string specific to a single project.

<connectionStrings configSource="CommonConnectionStrings.config" />


For this approach to work, the shared config file should be copied to the project’s output directory so it is adjacent to the regular App/Web.config file. Add the existing shared .config file to the project as a Linked file and set it to ‘Copy if newer’. You should see something similar to this in your .csproj file:

<None Include="..\CommonConnectionStrings.config">

Note that in the appSettings case, keys defined in the external file will override keys of the same name defined in the App.config file. Also, when deploying a web app to Azure, you can only override values defined in an external file if you use the configSource attribute.


It’s easy to copy/paste common code the first few times you need it. You can get away with it in a small application or prototype, but it’s better to practice applying the DRY principle. The next time you want to hit copy/paste, ask yourself if it would be possible to extract that information to a shared location in your project.

  • Kevin says:

    Have you ever tried using the parent child relationship when setting up multiple web application?

    Default Website
    +— web.config
    +— app01
    +— web.config
    +— app02
    +— web.config

    If you structure your system something like the above example, you can put your common settings, including connection strings in the web.config for the Default Website and they will be available to app01 and app02.

  • Comments are closed.