|
WCF comes with handful of tracing and logging options. We can just enable it with a few lines in the config and we are good to go. Furthermore the SDK comes with a handy tool svctraceviewer.exe (for wimps  ).
However, out-of-the-box trace output gives us access to the data/activities only in the WCF world. For example, at some point we might want to look at the HTTP headers sent/received by the application or we might want to check out the transport level frames are written properly in a custom transport. Although this is quite easy to do with a tool like WireShark or Ethereal, it still wants us to deploy the client and the service applications in two different machines (either virtual or physical).
I'm not done yet. In the end, under the covers, WCF also uses the well-known System.Net APIs at the transport level. Therefore we can just use System.Net tracing settings to capture the wire level traffic right from the dev box.
For example, to capture the http traffic we can use the following config settings.
<system.diagnostics>
<trace autoflush="true"/>
<sources>
<source name="System.Net.HttpListener">
<listeners>
<add name="FooNetTraceListener"/>
</listeners>
</source>
</sources>
<sharedListeners>
<add name="FooNetTraceListener"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="C:\dev\src\lab\wcf\WireLevelTracing\Logs\FooNetTrace.log"
traceOutputOptions="None"/>
</sharedListeners>
<switches>
<add name="System.Net.HttpListener" value="Verbose"/>
</switches>
</system.diagnostics> If you want to capture the traffic for a built-in tcp transport or a custom transport using System.Net.Sockets API; change to trace source to System.Net.Sockets.
|