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:
<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
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:
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.