Tools & Code: Making Sure Web.Config Parameters Exist

If you are working on an assignment as a single consultant, independent, or even an employee singularly responsible for his or her project, moving your project’s code base to the server environments whether it be development, user-acceptance, or production is always a stressful situation since no two server environments are ever the same and no server environment mirrors that of a local developer’s workstation environment.

In practically all cases in the environments I have worked in, the issues that have arisen from project moves are either security permissions or configuration. It is very rare to find a project that is working properly on a local workstation to suddenly cease working in a server environment due to something being wrong within the code base.

However, one area that can drive any technician to the brink of complete despair, especially when moving ASP.NET projects between environments, is newly defined application parameters that have been added into the “web.config” file. Most often the server web.config files are not touched by developers since they often include additional parameters unique to the server environment in which they reside. As a result, application specific parameters have to be promoted either by sending the appropriate server group the information or doing it on one’s own.

The biggest issue then is remembering to do this.

Under certain circumstances the lack of any such parameter can yield very ambiguous application errors that can take long periods of time to uncover given that many of us would have forgotten about a parameter update to a server’s web.config file simply due to stress and tensions. It happens because we are Human… Though, often enough that does not seem to be reasonable enough excuse for such a lapse.

There is a very simple way to always avoid such a situation with a little snippet of code that follows.

Most often when retrieving a parameter from the web.config file we simply use the following code:

string lsSQLConnectionString = ConfigurationManager.AppSettings.Get(“SQL_CONNECTION_STRING”);

To guarantee that a web.config parameter exists or have the application tell you that it doesn’t is by adding the following code to all such parameter retrievals within forms, code-behind modules and business objects while using a centralized error-handler component.

***** METHOD CALL IN BUSINESS OBJECT

string lsSQLConnectionString = Verify_WebConfigParameter(“SQL_CONNECTION_STRING”, ConfigurationManager.AppSettings.Get(“SQL_CONNECTION_STRING”));

***** METHOD IN BUSINESS OBJECT

private string Verify_WebConfigParameter(string psWebConfigParameterName, object poWebConfigParameterValue)
{
MyNameSpace.Classes.clsErrorHandling loErrorHandling = new MyNameSpace.Classes.clsErrorHandling();

return (loErrorHandling.Verify_WebConfigParameter(“ModuleName”, psWebConfigParameterName, poWebConfigParameterValue));
}

***** METHOD IN SUPPORT ERROR HANDLER OBJECT

public string Verify_WebConfigParameter(string psModuleName, string psWebConfigParameterName, object poWebConfigParameterValue)
{
string lsMessage = “Error: [ " + psModuleName + " ]“;

if (poWebConfigParameterValue != null)
{
return (poWebConfigParameterValue.ToString().Trim());
}

Insert_RecordIntoMessageLog(‘E’, lsMessage, “APPLICATION”, “parameter missing: ” + psWebConfigParameterName, “”);
Redirect_ToErrorPage(lsMessage + “
” + “parameter missing: ” + psWebConfigParameterName + “

“);

return (“”);
}

Trust me… This simple additional coding practice can save one a lot of embarrassment and stress in tight situations.

This code can be easily converted to VB.NET by making use of the excellent online conversion utility found at http://www.developerfusion.com/tools/

Black Falcon

About this entry

You’re currently reading “Tools & Code: Making Sure Web.Config Parameters Exist,” an entry on TECH NOTES

Published:
August 1, 2010 / 5:31 pm
Category:
Tools & Code
Tags:
, , ,