Since Logger is a static façade class, we can start calling the methods mentioned in the previous table without creating an instance. Internally, it creates a local instance of LogWriter using EnterpriseLibraryContainer.Current.GetInstance<LogWriter>() and forwards all the actions to the LogWriter instance.

The following code snippets demonstrate the usage of different overloads of the Write method of the Logger class.

Logging using the default category:

Logger.Write("Log Message");

Logging using a specific category:

Logger.Write("Log Message", "LOG CATEGORY");

Passing a little more information:

//Message | Category | Priority | EventId | Severity | Title
Logger.Write("Log Message", "LOG CATEGORY", 1, 1234, TraceEventType.Critical, "Log Title");

There are in total nineteen overloaded Write methods, each accepting a different set of parameters and helping us construct the LogEntry object internally using the information provided by us.

Special categories are nothing but out-of-the-box category sources provided by the Logging Application Block. We cannot add additional categories or remove these sources but we can provide one or more log destination (trace listener) to the special category source.

The following table lists the three special categories and their descriptions.

Logging a message with defined categories not only gives more context to the message but also allows finer control over it while deciding whether to turn on/off logging for a particular category. It is a good practice to decide the logging categories (for example, Debug, Trace, UI Events, Data Access Events, and so on) beforehand instead of logging into the default category (General). Category sources are defined in the configuration settings as part of the Logging Application Block configuration; a default category is also set while adding the configuration using the Enterprise Library configuration tool.

Let us add a new category in the categories section of the Logging Settings. Click on the plus symbol provided in the Categories section. Next, click on the Add Category menu item, a new category with default values will be loaded in the configuration tool as seen in the following screenshot.

We will add a category named UI Events; for the purposes of the demonstration the category name has been updated to UI Events. The following screenshot displays the newly added category:

Note that the default Event Log Trace Listener is mapped by clicking on the plus symbol against the Listeners and selecting the Event Log Trace Listener from the drop-down list.

The following is the list of configurable properties and their description:

Although we have already seen this trace listener in action as it is part of the default configuration, which was used while writing our first log message, we haven't yet explored the design elements and the available configuration options. Logging formatted messages to the Windows Event Log is provided by the FormattedEventLogTraceListener class and is part of the Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners namespace. This class inherits from the abstract class FormattedTraceListenerWrapperBase. The FormattedEventLogTraceListener class internally creates an instance of System.Diagnostics.EventLogTraceListener and passes on to its base class.

The following screenshot depicts the default settings without any association to the log formatter.

The following table provides a listing of all the configurable properties and their description. It will help in modifying the default behavior of the Formatted Event Log Trace Listener.

This trace listener writes log entries to a flat file using the configured log formatter. The FlatFileTraceListener class is part of the Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners namespace and inherits from the FormattedTextWriterTraceListener class.

Flat File Trace Listener allows to output log messages to a disk file. The following is a screenshot of the default configuration setting:

The following table lists the configuration properties and their description:

While logging to a flat file is a good option, sometimes we might want to log to new file based on the size or age of the file. The Rolling Flat File Trace Listener provides this functionality by allowing us to configure the size and time thresholds. The RollingFlatFileTraceListener class is part of the Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners namespace and it inherits from the FlatFileTraceListener class. The Rolling Flat File Trace Listener provides several properties to tweak the behavior of the listener through configuration.

The following screenshot displays the default configuration settings.

The list of properties and their description is given next. These properties can be configured to tweak the behavior of the Rolling Flat File Trace Listener.

This trace listener as the name suggests writes the log message to a file in XML form. The XmlTraceListener class is part of the Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners namespace and it inherits from the XmlWriterTraceListener class available in the System.Diagnostics namespace. It does not require a log formatter as it internally formats LogEntry or any class derived from LogEntry into an XML string using the XmlLogFormatter class.

XML Trace Listener configuration consists of three key properties: File Name, Severity Filter, and Trace Output Options, which might be modified to change the respective behavior.

The following screenshot shows the default settings of the XML Trace Listener:

The following table listing shows the configurable properties and their descriptions.

As the name suggests, this trace listener writes log messages to a database formatting the output using the configured log formatter. The FormattedDatabaseTraceListener class is part of the Microsoft.Practices.EnterpriseLibrary.Logging.Database namespace and it inherits from an abstract class named FormattedTraceListenerBase. The Logging block provides the database table schema and stored procedures to log messages in the database; the database script LoggingDatabase.sql and Windows command script CreateLoggingDb.cmd are available in the default source folder (EntLib50SrcBlocksLoggingSrcDatabaseTraceListenerScripts). Although the sql script generates a database named Logging, the script can be modified to create tables and stored procedures in our custom database as well. By default the command file generates the database, tables, and stored procedures in local instance of SQL Server Express; this can be customized in the command script file.

Database Trace Listener configuration involves setting of Database Instance and Formatter at the bare minimum; other properties might be modified to change their respective behavior.

The next screenshot shows the default settings of the Database Trace Listener:

The following table listing shows the configurable properties and their description:

The e-mail trace listener provides the ability to send log entries as e-mail messages to the specified e-mail address. This trace listener is feature-packed; it allows setting the authentication mode, from address, SMTP port and server, SSL mode, and so on. The EmailTraceListener class provides the implementation for this functionality; it inherits from the FormattedTraceListenerBase abstract class and both are part of the Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners namespace. Email Trace Listener configuration involves setting of several properties that are mandatory for the functioning of this trace listener.

The following screenshot shows the default setting of the Email Trace Listener:

The following table listing shows the configurable properties and their description:

The System Diagnostics Trace Listener is an interesting trace listener; it provides the Type Name property to configure the trace listener to be used from the list of available trace listeners. The following screenshot displays the default settings of this trace listener.

Apart from the common properties, the previous screenshot has two interesting properties. The Type Name property allows us to assign the fully qualified type name of the trace listener to be used while writing log messages. The InitData property allows us to pass initialization data to the configured trace listener.

The following table listing shows the configurable properties and their description:

The following screenshot shows the type selection dialog box with the list of available trace listeners derived from TraceListener:

We can select any trace listener from the list as shown in the above screenshot, for example selecting ConsoleTraceListener will write all messages to Console.Out or Console.Error.

The Message Queuing Trace Listener sends the log entries to the configured Msmq instance; the MsmqTraceListener class inheriting the FormattedTraceListenerBase abstract class, both part of the Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners namespace, provides the implementation for this functionality.

The following screenshot displays the default settings of Message Queuing Trace Listener.

The following table provides the list of configurable properties and their description.

The WMI Trace Listener raises a WMI event passing the LogEntry instance; this functionality is implemented by the WmiTraceListener class inheriting directly from the System.Diagnostics.TraceListener abstract class.

The following screenshot displays the default settings of WMI Trace Listener:

The following table provides a list of the configurable properties and their description:

The Logging block provides an abstract class called CustomTraceListener as an extension point for implementing custom trace listeners. Also, we may extend one of the existing trace listener implementations to satisfy our unique requirements.

Category filter configuration allows us to add one or more categories and set the filter mode to either "allow all except denied" or "deny all except allowed". The following screenshot shows how to add a category filter:

The following screenshot shows the default settings of the newly added category filter:

The following table shows the list of configurable properties and their description:

Logging enabled filter configuration is pretty straight forward, it just allows us to specify whether all logging activities are enabled or disabled by setting the All Logging Enabled property. The following screenshot shows how to add the logging enabled filter:

The following screenshot shows the default settings of the newly added Logging Enabled Filter:

The following table listing shows the available configurable properties and their description:

Priority filter configuration allows us to configure the maximum and minimum priority values based on which the log messages will be filtered. The following screenshot shows how to add a priority logging filter:

The following screenshot shows the default settings of the newly added Priority Filter:

The table below shows the list of configurable properties and their description:

We can trace application activities using the TraceManager class. This class exposes a method called StartTrace, which starts with the invocation of the StartTrace method and stops the tracing activity when the Tracer instance gets disposed.

The following code snippet shows how to initiate tracing and end the tracing activity:

//Create a TraceManager instance using the EnterpriseLibraryContainer
TraceManager traceManager = EnterpriseLibraryContainer.Current.GetInstance<TraceManager>();
using (traceManager.StartTrace("Tracing"))
{
//Perform application actions here
}

The previous code snippet first creates an instance of TraceManager using the EnterpriseLibraryContainer class. Next, we use the TraceManager instance and call the StartTrace method inside a using statement. This makes sure that the Tracer instance created internally gets disposed and the tracing activity ends with the disposal of the Tracer instance.

The following screenshot shows the typical log entry of a tracing activity:

The above given screenshot shows two log entries representing the start and end of the tracing activity with the timestamp, activity ID, ticks, and other details.

Implementing a custom trace listener is simple; we just need to inherit from the abstract class called CustomTraceListener. The CustomTraceListener class inherits from System.Diagnostics.TraceListener, also an abstract class exposing several virtual methods that can be overridden to provide the custom implementation. We have to add reference to the System.Configuration.dll assembly in the project while implementing custom trace listener.

The following code snippet shows the list of required namespaces for the custom implementation:

using System.Diagnostics;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Logging;
using Microsoft.Practices.EnterpriseLibrary.Logging.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners;

The folowing code block shows the implementation details such as ConfigurationElementType attribute, inheritance, methods to be overridden, and so on.

[ConfigurationElementType(typeof(CustomTraceListenerData))]
public class MyCustomTraceListener : CustomTraceListener
{
public override void TraceData(TraceEventCache eventCache, string source, TraceEventType eventType, int id, object data)
{
if (data is LogEntry && this.Formatter != null)
{
this.WriteLine(this.Formatter.Format(data as LogEntry));
}
else
{
this.WriteLine(data.ToString());
}
}
public override void Write(string message)
{
this.WriteLine(message);
}
public override void WriteLine(string message)
{
//Write to custom destination
}
}

The MyCustomTraceListener class inherits from CustomTraceListener and has overridden three methods: TraceData, WriteLine, and Write. We have to provide our custom logic to write the messages to the destination in the Write and WriteLine methods. It is to be noted that in the TraceData method we verify whether the parameter data is of type LogEntry; this check is carried out to ensure that the custom trace listener executes correctly outside of the Logging block. We also verify whether we have the formatter to format the log message; based on the outcome of the condition we write the message by passing the message to the WriteLine method. Also to be noticed is that the MyCustomTraceListener class is decorated with the ConfigurationElementType attribute with the input as CustomTraceListenerData; this attribute indicates the configuration object type to be used.

Configuring the custom trace listener

We have to configure the custom trace listener to leverage the trace listener; configuration is similar to what we have seen with other trace listeners. The following screenshot shows how to add a custom trace listener:

After clicking on Add Custom Trace Listener, a dialog box is displayed with the available types that derive from CustomTraceListener.

After selecting the required type and clicking on the OK button, the configuration editor will add the details to the configuration file. The following screenshot displays the added MyCustomTraceListener:

We are already aware of the common properties such as Name, Formatter, Severity Filter, and Trace Output Options. The property named Attributes comes in quite handy to pass additional configuration information to our custom trace listener.

A custom log formatter can be implemented by implementing the ILogFormatter interface. We need to implement the Format method that accepts a LogEntry instance and provides custom formatting logic to return the formatted string.

The following code snippet shows the required namespaces:

using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Logging;
using Microsoft.Practices.EnterpriseLibrary.Logging.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Logging.Formatters;

The following code snippet shows the implementation structure of a custom log formatter.

[ConfigurationElementType(typeof(CustomFormatterData))]
public class CustomFormatter: ILogFormatter
{
public string Format(LogEntry log)
{
//Provide custom formatting logic here
}
}

We have to provide the custom formatting logic in the Format method of the CustomFormatter class.

Configuring the custom log formatter

Configuration of the custom log message formatter is similar to that for Text Formatter and Binary Formatter; the configuration editor provides an option Add Custom Log Message Formatter. The following screenshot highlights the option:

Once we click on the Add Custom Log Message Formatter option, a dialog box to browse types that derive from ILogFormatter interface opens up. The following screenshot displays the dialog box with the selected custom log formatter:

After clicking the OK button, the configuration editor adds a new log formatter in the Log Formatters section. The following screenshot displays the newly added log formatter:

Attributes can be passed on to the custom formatter by providing the key and value details. Trace listeners will be able to select this custom formatter from the formatter drop-down list.

We will implement a simple custom log filter to understand the creation of custom log filters; this log filter implements the ILogFilter interface and uses the configuration element type CustomLogFilterData. The CustomLogFilterData class provides the infrastructure (configuration data) for custom log filters. This custom filter allows us to pass the required information as custom attributes. We will use this to pass the name of a machine that should not be allowed to write log entries.

The following code snippet shows the list of required namespaces for the custom implementation:

using System.Collections.Specialized;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Logging;
using Microsoft.Practices.EnterpriseLibrary.Logging.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Logging.Filters;

The following code snippet shows the custom log filter implementation that filters log entries based on machine name:

[ConfigurationElementType(typeof(CustomLogFilterData))]
public class MachineNameLogFilter : ILogFilter
{
string filterMachineName = string.Empty;
public MachineNameLogFilter(NameValueCollection attributes)
{
filterMachineName = attributes["MachineName"];
}
public bool Filter(LogEntry log)
{
return string.Compare(log.MachineName, filterMachineName, true) != 0;
}
public string Name
{
get { return "Machine name Log Filter"; }
}
}

The MachineNameLogFilter class is annotated with a ConfigurationElementType attribute of CustomLogFilterData; we have implemented a constructor that accepts NameValueCollection, which contains the attributes added in the configuration. The Filter method is at the heart of the action that determines whether the machine name matches with the log entry's machine name; if there is a match then the method returns false to stop the log entry from being written.

Configuring the custom log filter

Configuration of a custom log filter is pretty straightforward: click on the plus symbol provided in the Logging Filters section, navigate, and click on the menu item Add Logging Filters | Add Custom Logging Filter.

The following screenshot displays the configuration option to add custom log filters:

After clicking on the menu item Add Custom Logging Filter a type-browser dialog box will be displayed with the list of available custom log filters. The following screenshot displays the type MachineNameLogFilter:

Select the custom log filter and click OK button; this will add the custom log filter to the configuration editor. The following screenshot displays the newly added custom log filter; an attribute MachineName with the value has been manually added for your reference.

The configuration specified in the above screenshot will block all log entries with machine name as "machine1".