(Or why are there no variables in .Net’s Web.config)

The .net web.config file is kind of a pain when working with source control and multiple developers. I’ve been trying to figure out the best way to keep conflicts to a minimum, and allow for each developer to have different configurations (which is required for the current development environments).

So here is the crux of the problem. There are user defined setting in that file that look like this:

<appSettings>
...       <add key="OLAPCString" value="Provider=MSOLAP; Integrated Security=IIII; Data Source=QRSTUV;Initial Catalog=WXYZ;Cube Name=ABCD;"/>
...
</appSettings>
<connectionStrings>
...       <add name="ConnectionString" connectionString="Server=127.0.0.1;Database=TheDB;uid=TheUID;pwd=ThePWD;Max Pool Size=100; Connect Timeout=300;"/>
...
</connectionStrings>

There are many settings in both appSettings and connectionStrings that need to change based on the developers environment, but we also want to have a base version.

Setting it up with the developers directly adding / editing web.config will have web.config conflicting constantly. Often daily, eating into development time. As people add things to the file other developers will have to readjust the connection strings etc for their own environment. It gets really old really fast.

appSettings has an attribute “file” that lets you specify an external file that can override settings in the appSetting section – which is great. If that file exists, and a setting is defined there it uses that one, if the setting is not overwritten it uses the default one web.config.

That’s great, and solves half the problem, but what about connectionStrings? Well, there is an attribute “configSource” which allows you to have an external file but it’s an either or choice. You either define something in web.config or in an external file – it doesn’t override like in appSettings.

I am left scratching my head as to why that would be. It doesn’t make any sense. Why can’t you do the same thing as with appSettings (Well, Rob, because it simply is that way – he said to himself).

So, from what I can tell, we either:

1. Leave the connection strings in web.config and get svn conflicts

2. Move them to an external file, put the external file in svn and still get conflicts

3. Move to an external file, put a comment in the web.config and if someone adds something to connectionStrings (or we get new developers) have them add it to that comment and tell the developers to add it to their local file.

This seems overly complicated.

I tried to dance around this by doing something like the following on startup:

//get the developer defined connection string
string connectionString = ConfigurationManager.AppSettings.Get("ConnectionString");
//set the "real" connection string
WebConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString = connectionString;

<

p>but, of course, the connectionStrings connection string is readonly. Sigh.

<

p>I even tried adding entity references to the web.config in order to get around it:

 
<?xml version="1.0" standalone="yes" ?>
<!DOCTYPE configuration [
<!ENTITY server "192.168.1.100">
]>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
...

But that doesn’t work either for several reasons (I even tried to find a version of the schema to try to use a hacked version, but I couldn’t find one).

Square peg round hole.

Anyway, until we are enlightened, we’ve just decided to do the override for appSettings and just “waste” time dealing with the inevitable connectionStrings conflicts.

Anyone have any suggestions? Or is just a limitation of .Net development?

(On a positive note, the ability to completely override these sections, the configSource setting, makes doing deploys quite nice)