WCF Extensibility – System.Diagnostic Tracing

This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page.

This post takes again a detour from the normal flow of the series, as the extension I’ll be covering today isn’t a WCF extensibility per se, but it can be used to solve some real issues and since I’ve seen a post last week with an issue which can be solved exactly by the example in this topic, I decided to jump into tracing before going back to “normal” WCF extensibility.

Tracing is a very powerful tool in WCF. I think I've answered tens of questions in the MSDN forums with "enable tracing and find out the exception which caused the problem" and in most of the cases just that was enough for the the user to find out the issue – you look at the trace file generated by the diagnostic subsystem using the Service Trace Viewer Tool, look for the “line in red” (how the tool marks exceptions which were thrown or handled by the WCF runtime), and in most cases there will be the exception there explaining the problem. This is often seen in questions such “my client got a 400 response” or “the server forcefully closed the connection”. Notice that the tracing subsystem is a lot more powerful then just tracing exceptions (correlating a message between the client and the server, message time charts, etc.), but I’ll focus on the error aspect in this post.

This series is about places where one can hook up code to be executed in the WCF pipeline, but almost all of the examples of tracing I’ve seen simply add some information in the application configuration file which saves the traces in the file system for later analysis. But it doesn’t have to be this way. The tracing subsystem can also be extended, and it has been in the past for scenarios such as where one cannot access the trace file on a machine (i.e., in shared hosting environments) or to capture errors which the “normal” means (such as IErrorHandler) cannot detect.

The tracing subsystem is based on some sources which send data to a list of listeners. Many features in the .NET Framework act as event sources: System.Net and System.Net.Sockets (for networking traces), System.Runtime.Serialization (for traces in the WCF serialization subsystem), System.ServiceModel (the “main” WCF traces) and so on. All sources fire events to the subsystem under certain circumstances (e.g., when a message arrives to a WCF encoder, when some bytes are sent over a socket, when a new dynamic class is generated for serialization, etc.). The “Configuring Tracing” page on MSDN is the main source of information about tracing in WCF, and it describes the tracing sources in the platform. There’s one more missing from the list in that page, which is the System.Runtime.Serialization.CodeGeneration, which logs the IL generated (and executed) by the serialization subsystem for dynamic classes generated by WCF (to improve the performance of serialization / deserialization of objects). This is hardly ever used, though.

The listeners are simply subclasses of the abstract TraceListener class. As I mentioned, while most examples use one of the .NET classes (such as TextWriterTraceListener or XmlWriterTraceListener), one can provide its own implementation of the TraceListener and handle the messages from there.

    public abstract class TraceListener
    {
        public abstract void Write(string message);
        public abstract void WriteLine(string message);
    }

Read more: Carlos' blog
QR:

Posted via email from Jasper-Net