Tracing WCF with TcpTrace

Service Station, by Aaron Skonnard

Syndication

WCF provides built-in tracing at both the transport/application levels along with a helpful viewer program (SvcTraceViewer.exe). The problem with it's built-in "transport" tracing is that it traces the message just before it's written to the wire or just after it's read from the wire. It doesn't actually show you the raw byte stream transmitted on the wire.
 
However, if you've tried using a traditional trace utility (like TcpTrace), you may have hit a wall. WCF disallows unintended intermediaries for security reasons, which basically means if the To header doesn't match the endpoint address you're in trouble.  The way you get around this is by telling WCF what address you plan to route through. You can configure this on the client or within the service.
 
Service configuration
 
In the Feb CTP bits, you use the listenUri attribute on the service endpoint. For example, say your service normally listens on port 8080 and you wish to run TcpTrace on port 8383 -- to make this work, update the service endpoint configuration as follows:
 
<endpoint
   address="http://localhost:8383/myservice"
   listenUri="http://localhost:8080/myservice"
   binding="basicHttpBinding"
   contract="IMyService"/>
 
This causes the 8383 address to show up via WSDL/mex but the WCF listener is configured to listen on port 8080. When you run TcpTrace, you'd specify 8383 for the listen port and 8080 for the destination port. Then clients should send messages to the port 8383 address while TcpTrace is running.
 
Client configuration
 
Over on Commonality, the author shows how to set things up using the channelViaUri behavior in the client configuration file. Here's a summary:
 

<behaviors>

   <behavior name="tcpTraceBehavior">

      <channelViaUri viaUri="http://localhost:8383/myservice"/>

   </behavior>

</behaviors>

<client>

   <endpoint

      address="http://localhost:8080/myservice"

      binding="basicHttpBinding"

      contract="IMyService"

      name="myServiceEndpoint"

      behaviorConfiguration="tcpTraceBehavior"/>

</client>

 
You can also accomplish the same thing programmatically by manually adding a ViaUriBehavior object to the proxy's Endpoint.Behaviors collection as shown here:
 
MyServiceProxy proxy = new MyServiceProxy();
Uri tcpTraceUri = new Uri("http://localhost:8383/myservice");
proxy.Endpoint.Behaviors.Add(new ViaUriBehavior(tcpTraceUri));
 
With this config, you'd also run TcpTrace listening on port 8383, forwarding to 8080.
 
Either of these techniques allow you to trace WCF calls with TcpTrace -- you can choose based on which side (client or service) is easier to modify.
 
Update: thanks to Tomas at Commonality for filling in the client-side details.
 

Posted Apr 17 2006, 03:57 PM by Aaron Skonnard
Filed under:

Comments

Kirk Allen Evans' Blog wrote Web Service Geek? Go Read Pluralsight's blogs
on 04-20-2006 6:11 PM
I like to write in my blog, but I hardly read other blogs anymore.&nbsp; In fact, I don't have an aggregator...
John wrote re: Tracing WCF with TcpTrace
on 04-21-2006 5:08 AM
Thanks for the post! It worked like a charm in helping me uncover why WCF was choking when deserializing my message body.
Sajay wrote re: Tracing WCF with TcpTrace
on 05-24-2006 11:59 AM
I have the Feb CTP and I used the channelViaUri in the service configuration and it worked. Did you use the Feb CTP for the listenUri cause i have the FebCTP schema and this never showed up.
Commonality wrote Redirecting through TcpTrace with WSE and WCF
on 09-20-2006 11:10 AM
zithiat wrote re: Tracing WCF with TcpTrace
on 04-02-2008 10:30 PM
Hi all,
How can I use the tcpTrace only in commandline mode, not display the GUI?
Tk

Add a Comment

(required)  
(optional)
(required)  
Remember Me?