Sharing connectionStrings and appSettings between multiple projects

My last post talked about how to do this for appSettings via the file attribute however as I mentioned in that post the connectionStrings section unfortunately does not have a file attribute. It along with most other config sections only supports configSource which can only point to a config file in the current project. I did a bit more research and it seems configSource may be up to the job after all but only in conjunction with either Visual Studio file linking or build events to explicitly copy the master setting files.

Create your ‘master’ *.config files

OK first create a physical folder in your solution root called ‘Config’ for instance and lash your settings files in there. These are the master files you will be editing. Also replicate the physical structure with a Visual Studio solution folder as this is recommended so you can then easily manage the files via solution explorer. Additionally you should not have to explicitly tell TFS (if that’s what your using) about your new files if your replicate the physical structure with a solution folder.

Your structure might look something like the following:


Use the .config extension for security reasons as files with that extension won’t be served via a HTTP request.

Sharing config files by linking to them from consuming projects

For each project that needs to consume these master settings add a link to each of them. You can do this to each project directly or if like me you’d rather not clutter your root up you can create a dummy ‘Config’ folder (unfortunately virtual folders like solution folders do not exist on the project level) and add them as links to that folder. How links are added is very similar to the way regular existing items are added, however instead of just clicking ‘Add’ one must expand the dropdown and click ‘Add as Link’ instead.


After you have added the files as links your dummy physical folder will look very similar to folders with regular files but the files/links within it will have a slightly different icon beside them.


Now update your web/app.config and point your appSettings or connectionStrings section configSource to “config\localhost.appSettings.config” for example…


Now try two things.

Publish your project and notice how the linked files are ‘pulled in’ from the actual location for the purposes of deployment. In conjunction with a simple web transform to go from config\locahost.appSettings to config\live.appSettings etc. this means happy days, all works fine there.

Run your project in the IDE. It will fail at run time. That is because configSource is not able to follow links. It must point to an actual file and unlike during deployment Visual Studio does not ‘pull in’ the actual files (even temporarily) to the location that they are being link to from.

tooutputIf on each of the linked files we set the Copy to Output Directory property to “Copy if newer” or “Copy always” VS will put them into the bin/config folder. We can then prepend ‘bin’ to all our configSource references and VS will find the config files fine. I’d rather not have to point my configSource to anything in bin but this approach essentially solves what I’m trying to do.

When you publish again you will of course have a ‘Config’ folder in the package root itself but also in the package bin folder. You can remove the ‘Config’ folder from the root of the package by selecting “None” for the Build Action property on each of the links if you like.

Sharing config files by copying them with a pre build event

If you add the below XCOPY command into the pre build events box for project XYZ, Visual Studio or more precisely MSBuild will copy all files from the master ‘Config’ folder you created above to a folder called ‘Config’ in the XYZ directory.


If you point your configSource back to “config\localhost.appSettings” etc. Visual Studio will run fine because the physical files exist there.

Now however the problem is with the deployment.  When using the publish tool the ‘Items to deploy..‘ default of ‘Only files needed to run this application’ will not recognize the XYZ config folder with all the *.config’s in it as ‘needed’ as the XYZ project knows nothing about it and thus the package won’t have the required settings files to run correctly.

You can get around this easily by changing the ‘Items to deploy..‘ drop down box to “All files in this project folder“. This will work but personally I don’t like this though as it clutters the package and delivers the source code as is, not compiled into .dlls.


You could alternatively actually add a physical XYZ/Config folder and add copies of all the master config files to that folder and hence the project to ‘trick’ Visual Studio into recognizing the files in that folder as required. Of course the files in the XYZ/Config folder would always be overridden with files from the master config folder via the pre build event.

Which approach to choose. Link and Copy to bin or XCOPY to Config

I’m sure there are other ways to do this, and I have seen people wrap abstracted settings in class files but in terms of the above two well which method to choose really depends on your situation.

Both at the end of the day require copying of the master config files to somewhere where the configSource attribute can read them. It seems that if you go the linking route both deployment and running via Visual Studio will work fine if your OK with having your configSource’s pointing to bin. There’s also the small price to pay of needing a dummy physical folder as a hook to add the links to (I suggest adding a readme to this folder so other devs know what’s going on). Additionally ‘links’ don’t physically exist in your regular solution so you won’t have any problems with source control.

Choosing to copy settings files to arbitrary locations in the projects that need them has the potential to complicate deployment and force you to change the way you package up your files. Of course if you don’t deploy via Visual Studio or simply deploy everything in a project folder regardless of what Visual Studio has included in your project then everything is fine. With the build event approach the XCOPY copies all master settings each time you build, you don’t have to remember to explicitly link new settings files (localhost.nhibernate.config for example) from each project that needs them. Again source control will not be a problem as even though XCOPY does create actual files they will not be looked at by TFS or most other source control systems unless those files are explicitly added.

Leave a Reply

Your email address will not be published. Required fields are marked *