Build-specific application configuration

[Paul Norris]

This question is a bit academic now as my contract at this place is coming rapidly to a close. But for future reference, I'd be very interested in the answer. We're talking about .Net 2.0 and Visual Studio 2005. Don't limit your responses to this platform though; I'm interested in best practice rather than hacky work-arounds for an elderly platform.

The company where I've been working runs different DEV, SIT, UAT and PROD databases. They have connection strings for all four databases in their app.config file, but only one is uncommented at any given time. To do a SIT build, you have to uncomment the SIT connection string, comment out the DEV string, build, then revert app.config. This seems very clumsy.

I played with creating four separate build configurations Configuration Manager and then using the configuration variables in app.config. For example using something like

This didn't work and the connection string was returned as a literal.

I also found the tag in MyProject.vbproj: . I changed this to with some success. I could build the solution and run the exe from the target folder. But maintaining four separate replicats of app.config with the connection string as the only difference was worse than the problem I was trying to resolve. It also didn't work with the "Setup and Deployment" project.

I've come to the conclusion that adding a custom different constant to each build type in the "advanced compile options" for each build type in the main project would be a good approach. The difficulty is that each project has a copy of the connection strings and it becomes a maintenance issue. The up-side of app.config is that there is only one place where connection strings need to be maintained.

Does anybody else have a nice, elegant solution?

Cheers all,
Paul.

[adam_k]

If the only difference between the builds is the connection string, why don't you build a form that would allow you to change the connection string in the compiled apps? It doesn't have to be anything fancy, just which one is the "active" one.
I'd expect this to be in the login form. If you select from a drop-down list then you can't miss and if this drop down has an edit button next to it then I don't see where you will need to deal with the connection strings in your program again.

[Paul Norris]

Hi Adam,

Thanks for that. It's a good idea. But they don't use individual user logins so they're not using a login screen - they have an embedded, encrypted connection string specified in app.config.

It's a huge suite of applications - some running in batch/offline mode in a command window, one really big one running as a web server, and a few smaller stand-alone apps. They share a lot of code, including database interaction.

All this code uses the connection string. If I were designing this thing from scratch, I'd use a configuration-specific constant. But they client didn't want to refactor such a central piece of code because of the size of the regression testing load. I thought it would be nice if I could leave them with a nicer deployment process.

Any other ideas?

[adam_k]

Sounds like fun.
No ideas here, so good luck