Skip Navigation LinksHome > View Post

Using the SqlTraceListener with Enterprise Library Logging

This is part 5 in a series introducing the Ukadc.Diagnostics project which is currently hosted on codeplex at www.codeplex.com/UkadcDiagnostics.

I've been at pains to point out that Ukadc.Diagnostics doesn't aim to replace or compete with Enterprise Library (EntLib), log4net and nlog et al. In fact, in this post I want to talk about how EntLib and Ukadc.Diagnostics can work together.

Because EntLib logging was built using some of the core System.Diagnostics assets, EntLib users can actually utilize some compatible pieces of Ukadc.Diagnostics including the TraceListeners. In this example, we'll modify our example console application from the previous posts to use EntLib's Logger (note we've just commented out the SysDiag calls).

//private static TraceSource _source = new TraceSource("primes");

public static int CalculatePrimes(int topNumber)
{
    //_source.TraceEvent(TraceEventType.Start, 0, "CalculatePrimes");
    Logger.Write(new LogEntry() { Severity = TraceEventType.Start, Message = "CalculatePrimes"});
    
    BitArray numbers = new BitArray(topNumber, true);

    for (int i = 2; i < topNumber; i++)
    {
        if (numbers[i])
        {
            for (int j = i * 2; j < topNumber; j += i)
                numbers[j] = false;
        }
    }

    int primes = 0;

    for (int i = 1; i < topNumber; i++)
    {
        if (numbers[i])
        {
            primes++;
            //_source.TraceEvent(TraceEventType.Information, 0, "Found a prime: {0}", i);
            Logger.Write(string.Format("Found a prime: {0}", i));
        }
    }
    
    //_source.TraceEvent(TraceEventType.Stop, 0, "CalculatePrimes");
    Logger.Write(new LogEntry() { Severity = TraceEventType.Stop, Message = "CalculatePrimes"});
    return primes;
}

Now we need to configure the Enterprise Library Logging stuff:

<configuration>
    <configSections>
        <section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
        <section name="ukadc.diagnostics" type="Ukadc.Diagnostics.Configuration.UkadcDiagnosticsSection, Ukadc.Diagnostics" />
    </configSections>
    <loggingConfiguration name="Logging Application Block" tracingEnabled="true"
    defaultCategory="General" logWarningsWhenNoCategoriesMatch="false">
        <listeners>
            <add name="SqlTraceListener"
            type="Ukadc.Diagnostics.Listeners.SqlTraceListener, Ukadc.Diagnostics"
            initializeData="sqlSettings"
            listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.CustomTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
        </listeners>
        <categorySources>
            <add switchValue="All" name="General">
                <listeners>
                 <add name="SqlTraceListener" />
                </listeners>
            </add>
        </categorySources>
        <specialSources>
            <allEvents switchValue="All" name="All Events" />
            <notProcessed switchValue="All" name="Unprocessed Category" />
            <errors switchValue="All" name="Logging Errors &amp; Warnings" />
        </specialSources>
    </loggingConfiguration>

Notice that the listener we're using is the Ukadc.Diagnostics.Listeners.SqlTraceListener and the initializeData attribute is set to sqlSettings just like in the last post so we can reuse the exact same ukadc.diagnostics section. And here's the output as seen in the LogStore table:

SQL Trace Listener with EntLib

As you can see almost everything works just as expected. Wow. The main issue is that EntLib is pumping in a large pre-formatted message to the Message column. This is just the nature of the way in which EntLib works but we can easily workaround this without writing any code thanks to Ukadc.Diagnostics DynamicPropertyReader support.

All we have to do is change the Message parameter in the SqlTraceListener settings to read the data from Enterprise Library's LogEntry class. It's as easy as changing this:

<parameter name="@Message" propertyToken="{Message}" />

to this

<parameter name="@Message">
    <dynamicProperty
        sourceType="Microsoft.Practices.EnterpriseLibrary.Logging.LogEntry, Microsoft.Practices.EnterpriseLibrary.Logging"
        propertyName="Message" />
</parameter>

And here's the new output in the SQL table.

Results using the DynamicPropertyReader

Nice. And you could use this technique to read any property from the LogEntry class. If you've subclassed LogEntry you can even use it to read your own properties by changing the sourceType attribute to describe your own class. You could even write your own PropertyReader to read your data directly.

Also, the DynamicPropertyReader uses Lightweight Code Generation (LCG) to ensure the properties are read in a highly performant way (though this does incur a once per Appdomain compilation overhead).

Next we'll look at how you can use Ukadc.Diagnostics with existing TraceSources that ship with the .NET Framework.

 
Josh Post By Josh Twist
12:10 AM
02 May 2008

» Next Post: Cracking open Zip files in Silverlight Beta 1
« Previous Post: Using the SqlTraceListener

Comments are closed for this post.

Posted by Wes @ 13 Nov 2009 3:37 AM
Enterprise Library or Caching Application Block has some inherent drawbacks in it. So I think anybody using Enterprise Library or regular Caching Application Blocks, they should also keep into mind these drawbacks as well. I would suggest a research before going ahead. A good read can be found here <a href="http://www.alachisoft.com/ncache/caching-application-block_index.html">Enterprise Library</a>

Posted by WES @ 13 Nov 2009 3:39 AM
Enterprise Library or Caching Application Block has some inherent drawbacks in it. So I think anybody using Enterprise Library or regular Caching Application Blocks, they should also keep into min these drawbacks as well. I would suggest a research before going ahead. A good read can be found
here <a href="http://www.alachisoft.com/ncache/caching-application-block_index.html">Drawbacks of regular Caching Application Block</a>

© 2005 - 2014 Josh Twist - All Rights Reserved.