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.
