Multi-Environment WebConfigs for One WCF Installer (MSI)

Question

I've created a working Visual Studio 2008 "web setup project" that builds an MSI for my WCF web service.

I would like to provide 4 different web.config files, one for each of four environments (Dev, QA, Staging, Prod). In other words, I know what the connection strings and our other web services should be in each of those environments.

So when the admin runs my install, I'd like him to pick one of the four web.configs from a list, based on the environment name. This solves having to create manual instructions and chance for human error.

Right now, I'm working on adding a custom dialog screen to the "start" to ask which environment it is.

Thanks,

Neal Walters

Answer 1

1. Add a dialog box with four buttons. I named the button "EnvironmentButton".

2. I created a directory called CustomWebConfigs, with subdirectories called QA, STAGE, and PROD. Each one has a file called web.config. I used this disk structure so the file could always be called web.config and no need to rename it.

3. I did an "add file" for the CustomWebConfigs/Prod/Web.Config and set the "condition" property to "EnvironmentButton = "4"" (where 4 = PROD - the last of the four environments). NOTE: Use one equal sign - not two. I also switched to use values such as "PROD" instead of "4".

So far it seems to be working. Any comments or ideas appreciated.

1. I went found the property called "TargetName", so I dropped the nested directory structure above, and went back to having just four configs: web.config, webQA.config, webSTAGING.config, and webPROD.config. I added the last three as files, added the condition and set the TargetName of all three to just "web.config".

Answer 2

Another approach would be to externalize the WCF configuration sections into external file. That way, you'd have one single web.config, and a set of WCF sub-configuration file for each of your levels (QA, STAGE, PROD).

Your web.config would look something like (directory per level):

<system.serviceModel>    
   <behaviors configSource="QA\behaviors.config" />
   <bindings configSource="QA\bindings.config" />
   <client configSource="QA\client.config" />
</system.serviceModel>

or alternatively (level included in config file name):

<system.serviceModel>    
   <behaviors configSource="behaviors.test.config" />
   <bindings configSource="bindings.test.config" />
   <client configSource="client.test.config" />
</system.serviceModel>

That way, you'd have only a single web.config, a set of external smaller, easily manageable configs, and all you need to do is tweak your web.config (through e.g. XPath replacements or using XmlPreprocess for now - VS2010 will offer this functionality out of the box) to point to the right set of files.

That way, you won't be duplicating the rest of the web.config file, and possibly let those settings get out of sync when you update it in one of the web.configs, but not in others.