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:

Config
localhost.appSettings.config
localhost.connectionStrings.config
dev.appSettings.config
dev.connectionStrings.config
live.appSettings.config
live.connectionStrings.config

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.

link

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.

linked-in-solution

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

configSource

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.

build

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.

todeploy

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.

Common appSettings file for all projects in a solution

Many solution structures look a bit like below. This means that if some code in for instance MYSOFTWARE.APPLICATIONSERVICES requires access to an appSetting called XYZ all the launching projects (in bold) that use that code need to have XYZ specified in their web/app config files.

  • MYSOFTWARE
    • MYSOFTWARE.WEB.UI
    • MYSOFTWARE.DISTRIBUTEDSERVICES
    • MYSOFTWARE.APPLICATIONSERVICES
    • MYSOFTWARE.DOMAIN
    • MYSOFTWARE.REPOSITORY
    • MYSOFTWARE.TESTS

Depending on the amount of launching projects and the amount of ‘shared’ appSettings a solution contains maintainence of these settings can be problematic. It is therefore often useful to abstract out all solution wide appSettings into a single file which all projects reference. This is done via the file attribute on the appSettings section:

<appSettings file="../config/localhost.appSettings.config"></appSettings>

There are actually two ‘external’ related attributes on the appSetting section. These are  file as mentioned above and also configSource. Both will allow you to store settings outside of web.config/app.config. Only file however will allow you to load an external appSettings file which is in an arbitary location relative to the parent web/app config. The configSource on the other hand will throw an error if you try to ‘pull in’ your localhost.appSettings.config or similarly named file from a location other than the current project. That of course puts a spanner in the works in terms of being able to share a single appSettings file across all projects in a solution.

The other difference between the two is that with file, settings specified in the external file are merged with settings defined in the section itself, with the settings in the section itself taking precedence. With configSource however the external file is the only source of appSettings, meaning settings defined in the appSetting section itself are redundant.

If you take this approach you can then use web config transforms to swap out
..config/localhost.appSettings.config for ..config/dev.appSettings.config etc. when building your deployment packages. This means you transform one value rather than
multple values for X amount of appSettings.

Unfortunately the .net connectionStrings section only supports configSource and not file, so it’s not as easy to abstract out connections strings and share them between projects.

Register Castle Windsor IOC components via convention

Favouring convention over configuration means less change points (and remember points) for developers to deal with when new code needs to be added to software. My team tries to follow this guideline as much as possible but given the fact we are new users of Castle Windsor IOC, we were not aware that we could by convention have an IXXXService implemented by the first found XXXService.

We had code like the following in our IOC bootstrapper file:

Component.For<IUserService>().ImplementedBy<UserService>(),
Component.For<IAccountService>().ImplementedBy<AccountService>(),
Component.For<IFileService>().ImplementedBy<FileService>(),
...

which meant of course we had to explicity update the bootstrapper file if we created a new service. A new colleague started the other day and refactored to this:

Container.Register(AllTypes.Pick().FromAssemblyNamed
("MySoftware.Service").WithService.FirstInterface());

Now we only have to explicity register exceptions to the interface IXYZ being implemented by class XYZ rule. Pretty neat I thought.

We still use Castle Windsor 2, for Castle Windsor 3 I believe you need to use

WithService.DefaultInterface()