Should developers keep the web.config file updated and commit it to a VCS such as SVN? At my company we very rarely update it via SVN; instead somebody will create an “instructions” text file in our deployment scripts (SQL scripts and the like, plus batch files to compile the ASPX files as individual DLLs for deployment) that says something like “Change X to Y in web.config files for Sites A, B and D”, and relies on the individual developer following those instructions each time the file is updated.
This seems counter-intuitive to me: I would expect the web.config file to be kept in sync as needed, with necessary changes being made and the file committed as any other artifact of the codebase, but I have raised this issue in the past and nobody has paid it any mind.
What approach should be followed when dealing with config files like this?
Absolutely, web config must be in source control, and you can define differences beetween various versions of web.config with web.config configurations
for example we have one for local development server, one for test IIS server, and one for production IIS server. And we can set solution configuration and publish from visual studio for different targets and different clients (sites).
here are the links for web.config configurations :
Common Web.Config transformations with Visual Studio 2010
Web.config Transformation Syntax for Web Application Project Deployment