Have you ever had issues with changes inside your web.config file due the app is either in QA or development or production mode, etc.? Surely you have faced some of these seemingly minor difficulties in at least several of your projects. Especially if the app we are talking about is using various database connection-strings which are used for your testing purposes as well as in development and production.
What if I told you this process is easily automated? You will even get a drop-down menu for more pleasure and general satisfaction and the configurations will now be easily changeable for everybody on the team. All may be done from the environment that is already built inside Visual Studio. By the way, this will work on both automated/command-line builds as well as within IDE. Here is how you do it:
- Simply use your ASP.NET and Web Application Projects (they should have project files that are MSBuild).
- Open your VC config manager.
- Then create your QA or Development or Deploy or Staging or whatever build configurations that are applicable to your project as well as solutions.
- And so ad your entirely new web.config.qa or any other representative files inside your project
- Customize those files to have specific settings and configurations of the application contained.
- After all that done you should add a nice pre-build event command straight to your nice project file. It is supposed to copy your web.config automatically with the difference of the appropriate mode and with the specific version every time the project is built. So if your little solution is in the QA configuration then web.config.qa settings will get copied to your web.config file.
After all the mentioned above is done you will be able of choosing the mode from a drop-down menu just from the VS’s standard toolbar.
After you run/build for the next time (considering the configuration mode has been changed) VS will be modifying the web.config automatically and it will be picking up required settings on its own. You will gain from such an approach inside the source control environment and the trick works on your build server as well even if you are into some automated command-line builds. A nice little solution you have probably faced in your testing laboratories.