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.


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:


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:


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