First time here? You are looking at the most recent posts. You may also want to check out older archives or the tag cloud. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS. Thank you for visiting! (hide this)

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.

.NET 1.1

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.

.NET 2.0

"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.

Technorati tags: asp.net, configuration, VS2005

posted on Monday, April 23, 2007 3:28 PM

Comments on this entry:

# re: Managing application configurations in development teams

Left by Phil Scott at 4/24/2007 1:42 AM

We are starting a brand new project so I get to force people to use configuration data wisely. I'm a little frustrated that there isn't a good way to get a web.config easily shared amongst many developers if you aren't going for the merge changes approach to source control. Leaving things in appSettings or writing your own config sections that have a file attribute works OK until you run into situations like "I need to use a different role provider to debug some stuff on my machine, but Jerome has web.config checked out so he can run the project with tracing on."

It's annoying.

# re: Managing application configurations in development teams

Left by Steve Harman at 4/24/2007 2:43 AM

Phil, sounds like another point against using version control systems (like Visual Source Crap) which rely on a pessimistic locking strategy rather than an optimistic merging one.

# re: Managing application configurations in development teams

Left by Phil Scott at 4/24/2007 4:26 AM

I think it's probably more of a problem of pessimistic developers than the version control system. And honestly, we don't generally run into a lot of problems with the pessimistic approach besides the web.config situation. There are only three of us, and the vast majority of the time we are working on different parts of the project. In fact, I think in the two years I've been here I have yet to run into a situation where I needed to make a change to any file (besides web.config) that I couldn't edit because it was checked out.

It'd be nice if there was an option in VS2005 to say "hey, let me edit this sucker locally - it's cool, I'm not going to check it in." But I guess that would make the context menu quite wide.

# re: Managing application configurations in development teams

Left by Simone at 4/24/2007 9:54 AM

For the appSettings you can still use the file attribute, which still behave with the override method, than name the personal file as config.user, which will not be checked in by VSS (since all .user files are ignored).
But, unfortunately, the file attribute exists only for the appSettings

Comments have been closed on this topic.