More on sharing a config file

A couple of people commented on my post about sharing a config file between multiple developers.

Firstly, wow. I've had comments. That's nice.

Secondly, I don't think I articulated the problem too well. The title didn't help - it's not about working with multiple configuration files, or working with a config file across multiple environments, but on how to work with one config file that's being used by multiple developers with different needs. As an example, I want the web.config file to use a Microsoft Access based profile provider, while another developer wants to use a Sql Server profile provider. We both can't be right. We also can't both change the same file in source control, or there'll be trouble. The solution was to store the default config file under a different name and customise it per developer, with the customisations not included in source control. The post has the details.

Another comment was to ask why not use the configSource attribute? This attribute applies to any section element (i.e. xml element) and means that the contents of the xml element come from an external file. This sounds ideal, except it replaces the existing element, rather than overriding if the file is present. Since it replaces, the external file must exist, and we're back where we started.

(This raises questions on how useful this attribute is. It means you can make changes to a file and not have it restart the appdomain, you can set write permissions to a file that contains the appSettings section, so you don't overwrite existing config, and you can encrypt sections of the web.config by encrypting the external file.)

Similarly, there's a "file" attribute on appSettings, which does pretty much the same thing. It is more flexible, though - because you're dealing with a name/value pair collection, you can add to, remove from or clear and replace the web.config's appSettings section. It appears to be a hangover from .net 1.1, and unfortunately only applies to appSettings (which rules it out in my case - I need to change a child of system.web).

Hope this clears things up.