Sharing common connection strings between projects

If you are like me and are developing a visual studio solution which consists of multiple projects and you want to share the connection strings between them (for example — you may want to share a connection string between your MVC app and a unit test class library for integration tests ) without duplicating it, then you might find this post useful. To achieve this we’ll use a very handy property in System.Configuration.dll called ConfigSource.

First things first, lets define our connection strings. Typically if a file’s scope is solution wide I tend to create a Solution folder and call it Solution Items” and also create a physical folder on the disk to represent this. Lets create our connection strings file in this folder and call it ConnectionStrings.config””


Next, lets add a connectionStrings config section to it as follows:

    connectionString="Data Source=.;Initial Catalog=MyDb;Integrated Security=True"/>  

Now under you web/app config of you application add the connection strings sections again but point it to the connectionstrings.config file we just created, Visual studio will complain that the file path cannot be found. Dont worry about this for now, we’ll fix that in a minute.

  <connectionStrings configSource="ConnectionStrings.config" />

Next, add the connectionstrings.config file as a link to your application project by right clicking on it, selecting Add > Existing item from the context menu.


Next, select the newly added file and bring up the properties dialog and set the Copy to output directory” to Copy if newer. Rinse and repeat the same process for the other project in the solution and you are done. Why not apply the DRY principle to your solution infrastructure and avoid any repetition.

In some case you may have more than 1 external configsource file. For example, if you are developing a WCF service and also have a .net client within the same solution and you want to share things like Behaviors, Bindings, Endpoints etc. without repetition then you could use the same approach. However, having multiple external config files can clutter the overall project structure. One workaround is to create a folder in each project and add these external config files as a link under this project scoped Configuration folder as show in the image below:


But there is a problem with this approach, if you set the copy to output directory setting to Copy if newer” visual studio will create a folder called Configurations” under your output directory and the application will not be able to find these files at runtime. But worry not, there is a workaround for this problem too and it is discussed here on ever so useful Stackoverflow. To fix, all we have to do is right click on our project. Select Unload Project”. After it unloads, right click on project file again and select Edit project”, this will show us the xml structure of the project in the editor. Scroll right down to the bottom of this document and after the last ItemGroup xml element, add the following xml:

    <AvailableItemName Include="RootContent">

<Target Name="AfterBuild">
    <Copy DestinationFolder="$(OutputPath)" 
          SkipUnchangedFiles="true" />

Again, right click on the project, choose reload project, after the project reloads, select all the external config files under the configuration folder and now you have the option of making these files RootContent”.


By choosing this option the external config files will be copied to the output directory and not a folder within the output directory.

Up next A simple image carousel prototype using Asp.net webforms and SignalR Javascript Refresher
Latest posts Refactor react code to use state store instead of multiple useState hooks Notes on Python Threat Modelling - Using Microsoft STRIDE Model WCAG - Notes Flutter CI/CD with Azure Devops & Firebase - iOS - Part 1 Flutter CI/CD with Azure Devops & Firebase - Android - Part 2 How to samples with AWS CDK A hashicorp packer project to provision an AWS AMI with node, pm2 & mongodb Some notes on Zeebe (A scalable process orchestrator) Docker-Compose in AWS ECS with EFS volume mounts Domain Driven Design Core Principles Apple Push Notifications With Amazon SNS AWS VPC Notes Building and Deploying apps using VSTS and HockeyApp - Part 3 : Windows Phone Building and Deploying apps using VSTS and HockeyApp - Part 2 : Android Building and Deploying apps using VSTS and HockeyApp - Part 1 : iOS How I diagnosed High CPU usage using Windbg WCF service NETBIOS name resolution woes The troublesome Git-Svn Marriage GTD (Getting things done) — A simplified view Javascript Refresher Sharing common connection strings between projects A simple image carousel prototype using Asp.net webforms and SignalR Simple logging with NLog Application logger SVN Externals — Share common assembly code between solutions Simple async in .net 2.0 & Winforms Clean sources Plus Console 2 — A tabbed console window