Different (But Unified) Web.Config for Development, Production Websites

You obviously want to have different error handling in your site's web.config between development and production. However, since your root folder can only have one web.config, I had to maintain two separate web.config files (one in use on the development server, and one in a different folder, for uploading to production), and when I wanted to update a general setting that applied to both, it was a bit of a laborious process. In an ideal situation, the web.config would support conditionals, so I could have everything in one file, and it would apply different settings based on the environment, but that doesn't exist (note: I know there are ways to dynamically transform the XML, but that is a different animal, and I wanted to keep it simple).

I managed to figured out a pretty simple trick using symbolic links that allows me to keep one web.config for general settings, different error handling in external files, and the main web.config will grab the correct error config file based on the server it's on. There's a little big of setup, but it's a time saver in the long run when making web.config updates.

Here you go:

1) Create two folders - one for the development settings, one for the production settings.

2) Create a symbolic link on each server with the same name that points to the respective settings folder. For example, on my development machine, I would create a symbolic link "config" that points to "config_dev". On production, I would create a symbolic link "config" that points to "config_prod".

3) Move your error handling (or whatever you want to be different between the two environments) to separate files, saved in their respective config folder. Then link to the external file in your main web.config using the configSource attribute and pointing to the symbolic link, e.g., <httperrors configsource="config\httpErrors.config"></httperrors>

That's it - now, you can make a change to your main web.config on development > upload to production as-is > everything stays in sync, and your web.config can be checked in cleanly to subversion.

Published by

Hal

Aside from being a champion yo-yoer, I am the full-time computer geek at the American Society of Nephrology. I recently completed my MBA from George Washington University which I am hoping will enable me to finally afford my own bad habits. I also do freelance design, specializing in Flash, PHP, and ASP/ASP.NET.

Leave a Reply

Your email address will not be published.