Adding generic intelligence to ASP.NET configurations files

.NET configuration files are the perfect place to keep all your implementation specific information, such as server connection strings, banner content, etc.  However, when you are deploying in multiple environments, with say, a development environment, test environment, pre-production environment, and finally a production environment, one usually has to maintain a specific configuration file for each environment. 

Multiple configuration files bring a whole new set of headaches when it comes to testing.  Applications that work fine with one configuration file may fail spectacularly with another.   Changes common to all configuration files have to be synchronized and each configuration file needs to be managed separately under version control.

Wouldn’t it be nice if we had a single configuration file where the application just “knew” which settings to read, depending on the environment the application found itself in?  This brings us to the point of this article; in it I will present a “configuration helper” that will provide generic configuration file intelligence for all your .NET application.

To create the maximum flexibility for an application, configuration settings should be functionally isolated from the logic used to select the value, and the actual values themselves.  For example, an application may need to obtain the URL to a banner image located on another machine on the corporate intranet.  In this case the ASP presentation code could look like:

.In the configuration file we have the key:

Ignoring for a second the code behind, the presentation xml is calling the function ExpandText on the code behind instance which is responsible for looking up the string “(banner-url)”.   The ExpandText looks at the entire text string passed to it and replaces the braces and the brace enclosed text with the value of the configuration key it looks up.  The key being the text enclosed in the brace.  In this case, the key = “banner-url”, so the text string returned by ExpandText would be http://corp.net/images/common/mycorp.gif so far that’s nothing very exciting, but we have isolated the value of the URL from what we actually need to show functionally on the page.

Now for some magic, if we make the ExpandText function recursively expand text until no more braces are found, we don’t need to change our presentation xml to have different URLs returned depending on some other setting in the configuration file.

Changing the configuration file to contain:

Now using the same presentation code, but changing the key “switch” between values “internal” and “external” will give us different image URLs to display.  What happens here is that on the first call ExpandText expands the text string “(banner-url)” to become “((switch).unique-banner-url)”  since ExpandText recursively calls itself until no more braces are found,  the string “((switch).unique-banner-url)”  is then expanded to become “(internal.unique-banner-url)”  and once more expanded to become “http://corp.net/images/common/mycorPrivate.gif”.  Having the text look up be recursive allows us to isolate the lookup logic from the application.  All the application need to know is that it needs a “banner-url”, how it gets there is configurable.

Now let’s add a little more power to ExpandText.  If ExpandText can look up key in the configuration file, why not increase it’s functionality to lookup keys in other areas.

(key) looks up appSettings key values from the configuration file.

{key} looks up values from the page’s Request collection using HttpContext.Request[key].

[key] looks up values from the page’s Session collection using HttpContext.Session[key].

#key# looks up values from the page’s Application collection using HttpContext.Application[key].

%key% looks up values from environment values using Environment.GetEnvironmentVariable(key).

 If the key name begins with an exclamation mark "!", the mark is removed before key lookup and the expansion is returned as "true" if the lookup succeeds or "false" if the lookup fails. For example:  The expansion of string "{!AZD_USER_ID}" will return "true" if "AZD_USER_ID" is in the HttpContext.Request or "false" if it is not.  Also note that key expansion is recursive, meaning that the string resulting from a key lookup is itself expanded before being return. Key are looked up "depth" first.  That is, the inner most key is looked up first. For example if we expand the string "(a.(b.[c_{d}])" the keys will be expanded as follows: 1) The first key looked up will be "d" from the HttpContext.Request.                         2) Then "c_*result 1*" will be looked up from HttpContext.Session (where *result 1* is the result of the above lookup).                        3) Then "b.*result 2*" will be looked up from System.Configuration.ConfigurationSettings.AppSettings (where *result 2* is the result of the above lookup).                         4) Then "a.*result 3*" will be looked up from System.Configuration.ConfigurationSettings.AppSettings (where *result3* is the result of the above lookup).                        The result of the final lookup (result 4) will be return to the caller                        If a key is not found, then the key, including it's delimiters, are return intact.  For example, “xxx-(does-not-exist)”  will return “xxx-(does-not-exist)”. Using the above functionality we could then write a configuration file as follows: 

Using the above configuration file,  if the HTTP header “PROXY_USER_ID” is found in the http request header,  the user would see the mycorpPublic.gif,  if not found, the user would see mycorpPrivate.gif.  Assuming that a reverse proxy on the corporate intranet was configured to identify external users by including the HTTP header “PROXY_USER_ID” in all requests passed through it to internal ASP applications.  We now have an environmentally aware configuration file.  This concept could be expanded to change values based on any environmental change. 

Another common indicator might be to use the host name to indicate a change of environment. 

For example:

In this example the application code to connection to SQL might be:

 SqlConnection myconnection = new SqlConnection(ExpandText(Context,"(sql-connection-string)"));myconnection.Open(); The ExpandText method will lookup and expands “(sql-connection-string)” as follows: “(sql-connection-string)” is expanded to “(sql.(environment))” “sql.(environment)” is expanded to “(sql.(host.(host-indicator)))” “(sql.(host-indicator))” is expanded to “(sql.(host.{SERVER_NAME})” “(sql.(host.{SERVER_NAME})” is expanded to “(sql.(host.localhost)” “(sql.(host.localhost)” is expanded to “(sql.development)” “(sql.development)” is expanded to “Initial Catalog=MyDatabase;Data Source=localhost;Persist Security Info=False;Integrated Security=yes” As you can see this simple configuration helper method added to a .NET application provides a great deal of functionality to application configuration files. For the source file please see

ConfigurationHelper.zip (2.57 kb)