I am using the Microsoft Enterprise Library 5.0 Logging block and I wanted to know the difference between the LogWriter and the Logger classes. I have a few custom trace listeners that I have built to be used in my logging and I wanted to know if using Logger vs. LogWriter would have any effect.
From MSDN http://msdn.microsoft.com/en-us/library/microsoft.practices.enterpriselibrary.logging.logwriter.aspx
To write log messages to the default configuration, use the Logger facade. Only create an instance of a LogWriter if you need to write log messages using a custom configuration.
Example code #1:
namespace ExampleOne
{
using System;
using System.Diagnostics;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Logging;
public class Program
{
private static LogWriter logger = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();
public static void Main(string[] args)
{
try
{
throw new Exception("My test exception message");
}
catch (Exception ex)
{
LogEntry logEntry = new LogEntry();
logEntry.Message = "Error: " + ex.ToString();
logEntry.Categories.Add("General");
logEntry.Severity = TraceEventType.Error;
logger.Write(logEntry);
}
}
}
}
Example code #2:
namespace ExampleTwo
{
using System;
using System.Diagnostics;
using Microsoft.Practices.EnterpriseLibrary.Logging;
public class Program
{
public static void Main(string[] args)
{
try
{
throw new Exception("My test exception message");
}
catch (Exception ex)
{
LogEntry logEntry = new LogEntry();
logEntry.Message = "Error: " + ex.ToString();
logEntry.Categories.Add("General");
logEntry.Severity = TraceEventType.Error;
Logger.Write(logEntry);
}
}
}
}
The version that get's current instance is part way to being the better version because it would be easier to use dependency injection & hence make it easier to unit test incase the logger writes to the db or sends email or otherwise interacts with some large external component that has behavior unrelated to the code under test.
On the other hand, if the goal is to encourage logging on your team, then logging with minimal set up is the better option, but config will be config file driven & you'd need a separate config file for tests vs production.
Also, in real life organizations, you can't always expect the operations people to be web config (or in this case Ent Lib config) super ninjas and sometimes you need to provide UI that turns on logging and turns off logging or otherwise changes the behavior (like sending errors to a different mailing list/list of users) and that will require dynamic config. I've worked in organizations when changing logging behavior via UI was just an ordinary transaction but changing so much as a character of the web.config took a frickin act of god and the change control board.