Automatic change of web.config under source control during CI build

Question

I am working with couple of friends on an ASP.NET MVC website. The project is maintained in SVN and I have CC.Net set up to checkout latest version and do automated build and deploy to a pre-production server. The default build configuration is set to Debug, but the automated build is set to build Retail. Everything works just fine, except for the <compilation debug=""> in web.config which currently is set always to true. I'd like to be able to specify true or false for <compilation debug=""> based on the build flavor.

I've thought about two separate solutions to this problem.

I could have a pre/post-build step that modifies the value. However, the web.config file is under source control, so modifying it in the automated build will leave it checked out on the build machine. I could also have additional step that would revert it as well.

I could also instead of having web.config under source control, have a web.config.base file that is used as a source during the build to generate the web.config file. The problem with this approach is that most of the tools modify web.config directly and we have to manually merge such changes back in the base file. And since there's no indication when any tool changed web.config, we have to look for changes at any checkin. Not only this becomes a tedious manual step, but it's also error prone.

Both of these approaches would work, but have some shortcomings. I was hoping there's a more elegant way of doing this. Thus the question - how do you guys deal with modifying web.config that is under source control during the CI builds?

Answer 1

You can take a look at the Web Deployment Projects VS add-in. Scott Guthrie does a great job explaining it in this post.

Answer 2

Why not modify web.config as part of a build-step using a command line utility that can edit XML?

e.g. Obtain a command line utility that works like:

xml_mod.exe web.config [xpath-of-value-to-change] [new-value]

Then have different value per debug/release(retail)..

Answer 3

Why don't you just make the web.config read/write without checking it out from source control, make your changes you need during the build process and then discard them?

AFAIK SVN has the files read/write anyway.

Answer 4

we have a

• web.config for development
• web.config.cert which is deployed by hudson to our cert environment
• web.config.prod which is used for production

This allows us to put comments in there and values in there specific to the environments when that would normally have to go in some documentation somewhere, and it would surely be ignored.

Like I said, we have Hudson deploy to our cert environment on each build, so it just copies the directory over, deletes the web.config and renames web.config.cert to web.config

You may want to check out Hudson, I dont think I've ever heard of anyone choosing CC.net over Hudson if they had the ability to choose :)