Logging with Enterprise Library

As noted in the previous Logging blog post, the framework for our platform ended up using Enterprise Library 3.1. Some of the compelling reasons for choosing Enterprise Library over the alternative options were:

• Breadth of listeners and formatters for free with access to source code
• Config file driven design allowing you to turn on/turn off logging without changing a line of code
• Proven and tested components helping you build on top of them with a high sense of reliability

The logging component of our framework provides a simple design-time experience to developers, abstracting away the generic APIs that Enterprise Library provides:

This is essentially a façade to Enterprise Library (currently version 3.1) where implementation of Debug looks similar to:

public static void Debug(string log)

{

try

{

Logger.Write(log, CATEGORY_DEBUG); // CATEGORY_DEBUG is a string for category "Debug"

}

catch (System.Configuration.ConfigurationException configErr)

{

System.Diagnostics.Trace.Write(string.Format("Config info missing for Logger. Details: {0}. Exception is: {1}" , GetDebugInfo() , configErr.ToString()));

}

catch (Exception e)

{

System.Diagnostics.Trace.Write(string.Format("Error occured while logging the debug statement: {0}:. Exception is: {1}", log,e.ToString()));

}

}

Overloaded methods of Debug, Info, Warn and Error provide the consuming components to pass in context ids, severity for error messages among multiple others.

Consuming .NET applications (exe's, web site, web services, windows services) would:

1. Reference essentially only the framework assembly (don't need to add all the enterprise library assemblies)
2. Ensure appdomain's config file (app.config/web.config/.exe.config) has the requisite entries (In my next blogpost I will talk as how we went about automating this for SharePoint Web Applications)

Now all the developer would need to do is use the lightweight Log.Debug("Just log me")and the operations/engineering team can use tail/sql query/DebugView/trace listeners/event viewer/inbox to troubleshoot and/or analyze system issues

Comments

• Anonymous
  January 27, 2009
  The comment has been removed

• Anonymous
  January 27, 2009
  How did you find setting up the Enterprise Library logging stuff? I've looked at the EL stuff 2 or 3 times before, but just gave up when apparently I had to configure the configuration "blocks" -- it was extremely daunting. Compare this to, say, log4net, which took maybe 10 minutes or so to get rolling with. The idea of wrapping it is nice -- but what's it like under the covers? Was that a challenge at all?

• Anonymous
  January 27, 2009
  Michael, I would agree that trying to author the configuration blocks is not the easiest thing to do. Hence we would use EntLibConfig (which ships with Enterprise Library) to get the first cut of the config file. We made the deployment (or integration) of this config file into the main applications config file a trivial task using SPWebDeployment for SharePoint (you could use WiX to do the same for other types of applications) which probably will alleviate some of the pain points you mention.

• Anonymous
  January 27, 2009
  Phil, we had encouraged our developers to use the framework with prescriptive guidance such as: Debug: You would use this when you would like to log debug statements. Typically these would be your traceability statements helping you debug a given problem by using log statements. By default this level of logging will be turned off on production boxes once the code is stabilized. The implementation you describe sounds interesting but I am not sure how you are able to make the pipeline not process messages which are anyway going to be discarded?