Discussing the ins and outs of developing for SharePoint and the Microsoft platform

I have recently been looking into ways to make use of the Microsoft Enterprise Library 4.1in a client’s SharePoint environment, and one of the places I directed my attention to right away was the logging block. The Enterprise Library stuff makes it easy to configure all sorts of settings in the web.config file to control how your applications can log data, but the problem I found immediately was there was no way for me to tell it to log certain to the 12 hive logs in SharePoint – the solution is simple though, a very easy to put together custom trace listener.

The documentation that comes with the library had a great example of writing a custom trace listener so I based mine off that one, and given that we know you can log to the SP log files with a single line of code, this is going to be a really simple class. Check out the code here:

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

        public override void Write(string message)
        {
PortalLog.LogString(message, null);
        }

public override void WriteLine(string message)
        {
PortalLog.LogString(message, null);
        }
    }

Basically the TraceData method is the key here, it is what is called when your application is told to write something to your log source. Basically what we are doing in this method is determining if we are being told to write a LogEntry (which will have a formatter to it to control the text output) or just a flat string message. The bonus of doing this is that the formatter for the LogEntry is still configurable in the web.config file, so you can still control the format of what is logged to the 12 hive there the same as your other logging sources.

Outside of that method, the only two methods I needed to override here were “Write” and “WriteLine”. This is where the actual writing of the log data goes to the 12 hive. Very straightforward stuff here.

So moving on from this, I am in the process of standardising some error handling stuff using the exception handling block, and including the logging into that so the client can control what errors and messages in their custom solutions get logged to where (similar to what MOSS lets you configure for its OOTB functions through the central administration diagnostic logging screen).