tags:

views:

94

answers:

2

Dear ladies and sirs.

I wish to debug why my application sends so much data using WCF underneath. I tried to examine WCF trace logs and examine the traffic with Fiddler, but I need a stack trace leading to the offending client code.

So, I installed a custom IClientMessageInspector, but how can I know the size of the actual data given a Message instance? The ToString() of the given Message instance returns an XML, but I am not sure if its size is it.

Is there a way to hook into the WCF stack even deeper and closer to the actual sending of the message?

UPDATE

Found this SO question 1 year old, funny, but no one answered it - http://stackoverflow.com/questions/457683/message-size-after-serialize

+1  A: 

You mention the trace logs - but have you enabled message logging? With this in place, you should have clear visibility of the underlying messages, so you should be able to see exactly what data is on the wire?

Marc Gravell
I also want stack trace, live preferably.
mark
@mark - but at what point? You mention the message size - that is a transport concern, not a client / server concern...?
Marc Gravell
Thanks for clarification, is there a way to hook into the transport and see what is being transferred exactly? Or is IClientMessageInspector and IDispatchMessageInspector enough? Though, I cannot figure out how to get the length of the given Message instance...
mark
A: 

You can use the message interceptor, however note that "the body of a message can only be consumed ... once" (see msdn).

In essence you need to use Message.CreateBufferedCopy() to create a copy of the message to deal with as you like, including calling ToString() to dump it somewhere.

Also, when message interceptors are chained, you might not see the original message, but rather the one that the previous interceptor has created / altered.

So, if you really just want to see what is on the wire, you're probably better off with the builtin WCF tracing, as Marc already said.

Christian.K
I am aware of the tracing facility, but I want to examine the actual message during a live debugging session.
mark