My company maintains different environments--Dev, IT, UAT, Production, and Disaster Recovery--in which to run and test software solutions: particularly web solutions.  My company also (I think rightly so) places restrictions on what environments developers can access and which ones they can't--the old Segregation of Duties principle.  So, the question is, how do developers build applications mallable enough to run under different environments that can be deployed as simply as possible so as to not confuse the server admins and deployment personnel?

Our deployment vehicle of choice is the old Microsoft Installer file (MSI).  With regard to environment-sensitive settings, we simply "extend" applicable sections of the web.config to a second environ.config file.  There are always edge cases, but this approach seems to work out pretty well on the whole.  The following is an example...

Step 1: Abstract whatever environment settings to a separate file.  In this example, I use the appSettings section to house my configuration values, but this pattern works for most other sections I've tried (eg. connectionStrings)

In my web.config

<appSettings file="environ.config">
<add key="key1" value="someOtherValue"/>
</appSettings>

In my environ.config

<appSettings>
<add key="MyEnviron" value="Development"/>
</appSettings>

 

Interestingly, the appSettings node seems to be the only node that supports the "file" attribute.  All other configuration sections I've extended use the attribute "configSource".  I noticed the other day, though, that appSettings also seems to support the "configSource" attribute.  It looks like you need to be careful about your use of that attribute, though (see the Note in the description of the "file" attribute).

Step 2: Create other environment configuration files for the different environments you need to address.  In my example, I've created a IT.environ.config, UAT.environ.config, and Prod.environ.config.  Each configuration should look the same--only the values should change.


Step 3: Test your app to make sure it works in your "Development" environment with your default environ.config file.

Step 4: Now, add a web setup project to your solution to package/deploy your solution.  For simplicity, I've used Scott Guthrie's Web Application Project so I can easily add the Primary Output and Content Files to my web setup project.  On the Content Files output, make sure to add the ExcludeFilter: *environ.config.  This will exclude our environment specific config files--we'll add them in later.

 

Step 5: At some point, someone has to know/decide what environment your web app is being deployed into.  I contend that that decision should be made at the point of deployment.  That decision can be fairly easily automated (and I'll probably talk about that in a future post), but for now, we'll place that decision in the hands of the human installing your MSI on a given server.  

1. In Solution Explorer, right-click on your web setup project and select View > User Interface from the context menu.
2. In the User Interface tab, right-click on the Start node and select Add Dialog from the context menu.
3. In the Add Dialog dialog, select the RadioButtons (4 Buttons) choice and click OK
4. Move your new dialog to the appropriate order (usually after the Welcome dialog)
5. Set the properties of the dialog more or less as follows:

 

Step 6: Go back to the File System tab.  Under the Web Application Folder, one by one, add each of your environment config files.  For each file you will need to set two properties:

1. On the Condition property, set and equation like this: ENVIRON="Dev"
2. On the TargetName property, set the value to "environ.config"

Obviously, your Condition equation will change for each file.  For the Prod.environ.config file, the Condition property will be ENVIRON="Prod".

 

Step 7: Finally, build your MSI and test it out.  When you choose, say, the UAT environment, make sure that your UAT config file gets deployed and renamed appropriately.  Attached is a sample app for your perusal.
 

 

MSIEnviron.zip (568.92 kb)