Improving Using XML to Share Constants Across ProjectsBy Rachael Schoenbaum
In an earlier article of mine, Using XML to Share Constants Across Projects, I looked at how to share common constants across multiple ASP.NET Web projects using a "constants XML file" and a custom class (
ConstantsManager) to read this file and pick out particular constant values. Since publishing that article, I've improved the class and file structure to allow for constants specific to a particular development phase or environment. For example, a constant that you might need to have access to is the mail server to use to send emails. However, the mail server to use might be different when testing, staging, and when the site goes live. In this article we'll look at how to extend my earlier article to allow for the constants file to have versioned constants.
ConstantsManager Class and Multiple Environments
The problem with the
ConstantsManagerclass as it exists in the first article, is that every time you roll your application out to staging or to production, you have to go in a modify the config file for values that are different across the different environments (like database connection strings, paths on the file server, and URLs). It's easy to forget which variables need to be modified and what they should be modified to. Plus, every time you touch the code, the likelihood for introducing errors grows.
An additional consideration is that not all constants are affected by different staging environments. For example,
things like the number of search results that display per page or length of the columns in the database will remain
the same across environments. My challenge, then, was to come up with a way to modify the
ConstantsManager class to allow for an optional tag that indicated which environment (if any) the
constant applied to without requiring modifications to the projects. The rest of the article describes in
detail I accomplished this.
Modifying the Config File
To prepare the config file for this new concept, I first decided that I needed some mechanism to specify what version should be used. I decided to add a single new tag to the config file -
THIS_VERSION- that would indicate what version of the constants to use. That way, when moving from one environment to another, all I would have to do was modify the value of this tag.
Next, for those constants that need to have different values for different versions,
I added a
version attribute. Imagine we had a constant named
APPLICATION_URL, that had
three different versions for, say, testing, staging, and production servers. The constant file, then, would contain
APPLICATION_URL elements, each with a differing
version attribute like so:
Of course not all constants require different values for different versions. For those constants, you can simply
use just one tag and omit the
version attribute altogether:
To handle the versioned constants, the
ConstantsManager code needs to be changed slightly. The following
shows the complete code for this class, with the changes from my first article
shown in red.
Using the New
Using the new
ConstantsManagerclass is absolutely no different than before. It's no different because the current version information is stored in the
<THIS_VERSION>element in the constants file itself. An example of using the
ConstantsManagerclass in an ASP.NET Web page is shown below:
The manager pulls the value for the tag indicated. If the tag has a version, it only uses the version that matches
what's in the
The best part of this enhancement is that if you're already using the
ConstantsManager class, upgrading
to this improved implementation requires no changes to your existing code base. The benefit to this methodology
are that all of your constants for all different environments live in one file and you only have to change one value
in the constants file to update your config file for your new environment. This makes roll outs easier and less
About the Author
Rachael Schoenbaum is a developer specializing in ASP and VB.NET, ASP/Visual Basic, SQL Server, XML, and related technologies. She consults for Lucidea and has been programming since 1999.