s you've seen in the previous chapters, WCF offers numerous options for configuring your distributed applications and for extending WCF with custom code. Combine that with the complexities of cross-machine and even cross-company interactions and you have many places to look for sources of unexpected behavior.
Debugging distributed applications can be a challenging prospect. Even if you do have access to the processes and symbol tables necessary for stepping through flow across service call boundaries, remote logic might have been created by a different team with different coding and execution practices. There is also the difficulty of filtering diagnostic information to isolate a particular flow of execution—for example, a single user's session across multiple services and machines.
However, the challenge of any distributed system is not only its initial development, but ensuring ease of maintenance as that application is utilized in production scenarios. IT administrators need efficient means for finding root causes of issues so that the responsible company and development team can be notified.
Fortunately, WCF has a number of built-in features and tools for diagnosing causes of issues, often without much more effort than electing to enable those features in your configuration files. As you'll see in this chapter, WCF utilizes and builds on the native tracing and diagnostics features of the .NET Framework. This allows you to leverage your existing knowledge, and it enables integration of WCF applications' diagnostics with those of other applications.
In this chapter, we describe how to use tracing facilities to capture WCF events and logging to capture details of exchanged messages. Trace listeners are described, along with examples that show how to configure the settings for different events. The Service Trace Viewer, a powerful tool that is included with WCF, is also described, which enables you to inspect activities across service call boundaries.
Sample WCF Application
This chapter uses the SelfHost
sample application that is included with the Windows SDK. Details on obtaining, configuring, and running the sample can be found on MSDN at http://msdn2.microsoft.com/en-us/library/ms750530.aspx
. If you have the SDK installed, you'll find the SelfHost
application under Basic\Service\Hosting\SelfHost\
with both C# and VB.NET versions available.
is an introductory sample consisting of simple service and client Windows console projects. The client console application makes several calls to the WCF service, and results are displayed on both the client and service consoles.
The core diagnostics capabilities of WCF build on the existing tracing facilities provided by the .NET Framework itself. The System.Diagnostics namespace includes classes that enable applications to easily emit tracing information and store those details in a variety of formats and locations.
System.Diagnostics features tracing capabilities organized around the concepts of trace sources and trace listeners. Trace sources
are configured using the System.Diagnostics.TraceSource class and enable applications to emit details of execution, such as data or events. The traces emitted by a trace source can be received and processed by one or more trace listeners
, classes derived from the abstract base class System.Diagnostics.TraceListener.
WCF natively utilizes these features to emit details about the actions occurring during the processing of service calls and responses. No custom code is required to create these details and the developer or IT administrator need only add configuration to enable the source and listener, as described next. However, developers are free to add their own tracing calls to emit additional details as desired.
A central feature for monitoring WCF applications is called end-to-end (E2E) tracing
. This concept utilizes System.Diagnostics features of the .NET Framework to pass identifiers between the various entities of a distributed application so that their actions can be correlated into a logical flow. Using E2E tracing, it is possible to follow a sequence of actions across service and machine boundaries—for example, from request origination on the client through the business logic invoked by the target service.
E2E tracing uses a specific XML schema to persist details of processing across logical boundaries. The XML is created by registering an instance of the System.Diagnostics.XMLWriterTraceListener, which processes trace information into the E2E XML format (defined at http://schemas.microsoft.com/2004/06/E2ETraceEvent
The code below shows an abridged E2E trace XML fragment:
<Source Name="System.ServiceModel" />
Note in particular the Correlation
node and the ActivityID
property. These are the keys to combining individual trace fragments from a variety of sources into a unified logical flow. The concepts behind correlation are described next.