A common scenario in team development, but even more common in open source projects, is that developers working on the same project can have different setup environment:
- different connection strings
- different path to reach specific folder or configuration files
- maybe even different url to reach some webservices
- different smtp servers
- and so on ...
The best solution is to have the user (during that post user===developer) being able to specify his own specific settings without having to modify the main web.config.
In the .NET 1.1 all the configurations were inside the <appSettings> section of the web.config file, so an easy way to accomplish that task was to add a file attribute with an user specific configuration file. If the file was present, then the runtime would read settings from there, otherwise it would read from the main web.config file.
"Unfortunately" in .NET 2.0 the settings are shattered around many sections in the web.config file, and all the configuration sections other then <appSettings> don't have a file attribute. So you cannot use the same approach as with the .NET 1.1
But all have a configSource attribute. But it works differently from the file attribute: while the file specified inside the file attribute was overriding the configurations in the main web.config, the file specified in the configSource attribute is an alternative way to specify the configurations.
So, for example, to specify a user configurable connection string that's what you have to do:
on the main web.config
<connectionStrings configSource="user.config" />
on the user.config file
<connectionStrings> <add name="subtextData" connectionString="Server=localhost;Database=SubtextData;Trusted_Connection=True;" /> </connectionStrings>
I prefer the way the file attribute worked in the .NET 1.1, because it provided a way to specify a default configuration and everything worked also if the user configuration file was not present.