Service tracing in WCF reminds me of the continuum transfunctioner--its a very mysterious and powerful device and it's mystery is exceeded only by it's power.

I had some WCF problems recently and ended up having to open up a ticket with Microsoft to resolve.  The first thing the tech did was send me an email with the following configuration:

    <system.diagnostics>
<sources>
<source name="System.ServiceModel" switchValue="Warning, ActivityTracing" >
<listeners>
<add name="xml" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging" switchValue="Warning">
<listeners>
<add name="xml" />
</listeners>
</source>
</sources>
<sharedListeners>
<add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="Server.svclog" />
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>

and...

    <diagnostics>
<messageLogging maxMessagesToLog="30000"
logEntireMessage="true"
logMessagesAtServiceLevel="false"
logMalformedMessages="true"
logMessagesAtTransportLevel="true">
<filters>
<clear/>
</filters>
</messageLogging>
</diagnostics>

The first thing to note is, "wait a minute: there's two sets of configuration just to get trace logging going?" Why, yes, Timmy, that's right! The node system.diagnostics lives directly under the configuration document element while the node diagnostics lives under system.serviceModel. The second thing to note is, "hey, this looks like a much simpler diagnostics configuration than I'm used to!" Prior to my exchange with this Microsoft tech, I would just go in to the WCF Service Configuration Editor tool and just start click on different links in the Diagnostics page. I'd usually produce a configuration like this:

    <system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">
<listeners>
<add type="System.Diagnostics.DefaultTraceListener" name="Default">
<filter type="" />
</add>
<add name="ServiceModelMessageLoggingListener">
<filter type="" />
</add>
</listeners>
</source>
<source name="System.ServiceModel" switchValue="Warning,ActivityTracing"
propagateActivity="false">
<listeners>
<add type="System.Diagnostics.DefaultTraceListener" name="Default">
<filter type="" />
</add>
<add name="ServiceModelTraceListener">
<filter type="" />
</add>
</listeners>
</source>
</sources>
<sharedListeners>
<add initializeData="d:\somedir\tests\dummywcftests\wcfservice1\web_messages.svclog"
type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
name="ServiceModelMessageLoggingListener" traceOutputOptions="Timestamp">
<filter type="" />
</add>
<add initializeData="d:\somedir\tests\dummywcftests\wcfservice1\web_tracelog.svclog"
type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
name="ServiceModelTraceListener" traceOutputOptions="Timestamp">
<filter type="" />
</add>
</sharedListeners>
</system.diagnostics>

and...

    <diagnostics>
<messageLogging logMalformedMessages="true" logMessagesAtTransportLevel="true" />
</diagnostics>

The log file produced wasn't much help, either. As soon as I loaded this new configuration (sent to me by the tech), recreated my problem, and looked at the log in the Service Trace Viewer tool, I knew immediately what my problem was (it was even bolded and in red)! Fortunately (or maybe unfortunately), I had other problems with my service so I still made good use of the technical support.

One thing I really like about this new configuration is that all traces are dumped to the same XML listener. As far as I can tell, there's no way to route different trace sources to the same listener in the configuration tool. You'd have to drop out of the tool and edit the XML directly. The tools Microsoft provides are great: but you'll likely still need to edit the generated code/configuration at some point.