The Spin

You have DEV, QA, SIT, UAT and PROD environments in your shop. Each environment has its own database connection, username, password, logging, etc. settings. You could deploy a distinct config file for each environment. This introduces complexity into the build process and increases the chance of error. You could comment out sections of your configuration but the same problems exist.

In Java, it is common to use the application server’s JNDI abilities to access database connection (among other) parameters so that the app does not have to have hardcoded values. This separation allows for a more dynamic, trouble free deployment. The DEV application server has the DEV settings for your app and your app now how to ask for those settings.

To my knowledge, IIS and the .Net Framework, as an application server, do not have a defined method of handling custom variables for application’s use. So, the task to tackle was to provide a standard means by which applications can configure themselves at runtime based upon the server they are running on.

My solution was to create a DLL that can be included into a .Net application. This DLL must work with both .Net 1.x and 2.x applications for backward compatibility. One of the niceties of .Net is that since code is compiled into CLR, the DLL can be used with both VB.Net and C# programs. In addition, the library can be of benefit to web, console and winforms apps equally.

So, what does it do and how does it work? After including the DLL as a reference, in the main method of the app (or in the case of a web app, in the global.asax file) you’ll find the environment.

GetEnvironmentVariable(“RuntimeEnv”).ToString().ToUpper()

As you can see, the DLL looks for the environment variable on the Windows Server itself: RuntimeEnv=DEV for example. Based on this lookup and armed with the knowledge of where it is executing at runtime, the app can then take additional action: looking up the values we want from the config.

<code>
<configSections>
<sectionGroup name=”runtimeEnvironments”>
<section name=”DEV”        type=”DLLAssemblyName.HandlerClass, DLLAssemblyName” />
<section name=”QA”          type=”DLLAssemblyName.HandlerClass, DLLAssemblyName” />
<section name=”UAT”        type=”DLLAssemblyName.HandlerClass, DLLAssemblyName” />
<section name=”PROD”      type=”DLLAssemblyName.HandlerClass, DLLAssemblyName” />
</sectionGroup>
</configSections>
</code>

Using configuration lookup, we’ll grab the section and parameters for the environment we’re running on like these encrypted strings (to be decrypted later).

<runtimeEnvironments>
<DEV
username=”DFGfdfgf7474hfh”
password=”SDFsdfsd77#@”
server=”SDFGdsfgf89747s#$WDff”
/>
<QA
username=”DFGfdfgf7474hfh”
password=”SDFsdfsd77#@”
server=”SDFGdsfgf89747s#$WDff”
/>
<!– Etc… –>
</runtimeEnvironments>

Since we don’t know all of the key/values that a app may need, the DLL loops over them and enters them into a Hashset. We can then grab a reference to the Hashset and pull the items out by key as needed.