WCF - Inspect the messages being sent/received?

Question

I have 2 solutions: - Server Solution - Client Solution

The server registers itself to my localhost IIS: http://localhost/MyApp/

The client adds WCF Services (Service References) from the localhost application: http://localhost/MyApp/MyService.svc

When I'm running the client I want to be able to see the messages being passed back and forth. I downloaded Fiddler, but it doesn't seem to want to show me any traffic being sent unless I actually use a web browser. Am I using Fiddler wrong or is there another tool I should be using for this?

---

To clarify, what I'm looking to do is to see the actual messages being passed in. I don't want to do anything with them except see them visually with my own eyes.

I like the WCF Service Log Utility, but I don't think I have the correct setting on there. I can't see the actual soap message, just that a message was received.

And also to clarify further, I don't care what tool I use as long as I can easily see the messages themselves.

Baelbeer

Answer 1

To view the message contents you must add a source for System.ServiceModel.MessageLogging in your configuration file. The message tab in the Trace Viewer will show the full message for a particular service call.

Here is a sample configuration file:

<configuration>

...

   <system.diagnostics>
      <sources>
         <source name="System.ServiceModel"
                      switchValue="All"
                      propagateActivity="true">
            <listeners>
               <add name="traceListener" />
            </listeners>
         </source>
         <source name="System.ServiceModel.MessageLogging"
                      switchValue="All">
            <listeners>
               <add name="traceListener" />
            </listeners>
         </source>
      </sources>
      <sharedListeners>
         <add name="traceListener"
                 type="System.Diagnostics.XmlWriterTraceListener"
                 initializeData="c:\Traces.svclog" />
      </sharedListeners>
   </system.diagnostics>

   <system.serviceModel>
   <diagnostics>
      <messageLogging logEntireMessage="true"
                                  logMalformedMessages="true"
                                  logMessagesAtServiceLevel="true"
                                  logMessagesAtTransportLevel="true"
                                  maxMessagesToLog="500"/>
   </diagnostics>

...

</system.serviceModel>

...

</configuration>

See the Configuring Tracing topic on MSDN for more information. http://msdn.microsoft.com/en-us/library/ms733025.aspx

Segno

I had to remove propagateActivity="true" from System.ServiceModel.MessageLogging and then this worked for me – Thermal

This solution worked for me (along with Zane's annotation), where other proposed solutions I found were incomplete. – Mock

If you confirmed that propagateActivity="true" should be removed, why not fix the answer? Thank you. – Effeminate

The choice to use propagateActivity or not depends on your specific scenario. The msdn page I referenced in the answer explains, toward the bottom, when and why you might want to use propageActivity. – Segno

Answer 2

Maybe I'm missing something, but... Why don't you use the WCF tracing features? It's a fantastic troubleshooting tool. I've used it for services hosted in IIS/WAS also.

Enabling WCF Tracing

BTW, some people don't know it, but you can open traces from server side and client side at the same time, and the Viewer will show you the correlation between the server and client actions in a nice graph.

EDIT: whenever I had to capture TCP/IP traffic, I use WireShark. If you need to do it programatically you can use SharpPCAP, so I can take actions upon what I capture from the network. But for troubleshooting, much much better to rely on WCF Tracing.

Aggressive

@Drew Marsh: That's impossible to say, IMO, as we don't know exactly which purpose @Baelbeer wishes to see the messages for. It's one thing to see them for tracing purposes, another because you want to possibly mod them or perform some other sort of notification. – Perforce

@Perforce The OP was trying to use Fiddler to see them, so I think it's pretty clear they're doing it for diagnostic purposes. – Antakiya

@Drew Marsh: I realize I'm being pedantic here, but you are inferring @Baelbeer intention based on the tools he's using, not on any evidence or statement of fact. I've used fiddler many times for the purposes of looking at a message before I go and want to modify how it is sent. That is not a diagnostic purpose. – Perforce

I'm trying to see the SOAP messages passed into my server, not do anything with them... just see them. – Baelbeer

I keep seeing this answer it does not work for me. I want to see the complete incoming and outgoing message. It's amazing the WCF doesn't provide this. This was trivial to do with ASMX. – Abuzz

On Windows 8 you must run your application elevated (Run as Administrator) in order for your application to generate trace logs. – Haleigh

Thanks for the answer. It has just helped me tremendously. – Televisor

Anyone has encountered this issue(no packets out)? #41600499 – Boon

Wireshark wont help you if you're doing https – Hydrocephalus

Answer 3

If you want to inspect messages programattically, you can implement an IClientMessageInspector interface and register it with your client.

This allows you access to all of the messages, no matter what binding you are using, whereas using tools like Fiddler will only allow you to inspect messages using the HTTP transport channel.

Note, that using this technique, you can do much actually modify the messages or do much more (fire off notifications, for example). If all you wish to do is put your eyes on the message, then using tracing might be an easier approach for you.

Perforce

The IClientMessageInspector does not capture the final output. I was relying on this method to view my outgoing messages and it wasn't capturing a security header. I wasted a couple of days because of this. I assumed the header wasn't there but I finally pointed my client at an ASMX web services server that had the good old fashioned message logging that really worked pre-WCF and I saw that my header was actually there. – Abuzz

Answer 4

Is your service SOAP or RESTful? You can use the WCF Service Trace Viewer Tool to view the SOAP message headers and bodies. Instructions for configuring your web service for tracing are here.

Yachting

I'm trying to see the SOAP messages being passed into my server. – Baelbeer

@michael, yep you can use the WCF trace viewer for that. I updated the link with better instructions. You need to instrument your web.config to enable tracing in your SOAP service. Using the tool, you'll see all the request messages hitting that service. – Yachting

@retrodone: The instructions still point to the same urls (in fact, they're the same link). I did what it said in those links and I get the Trace.svcLog file, however I don't see the actual message in there even if I set the switchValue to All. I see that a message came in but I don't see where I can see the actual soap message itself in xml format. – Baelbeer

@michael, sorry. The Service Trace tool is pretty complicated. You may get better results with WireShark or Fiddler. But, take a look at this post which shows you how the SOAP messages appear in the Service Trace tool. – Yachting

Answer 5

In WCF we can use another way to see actual SOAP messages - custom MessageEncoder - a low-level pipeline extensibility point. Unlike message inspectors (IDispatchMessageInspector / IClientMessageInspector) it sees original byte content including any malformed XML data. You need to wrap a standard textMessageEncoding as custom binding element and adjust config file to use that custom binding.

Also you can see as example how I did it in my project - wrapping textMessageEncoding, logging encoder, custom binding element and config.

Becerra

Answer 6

Look at this StackOverflow thread: How to use Fiddler to monitor WCF service

It answers some of your questions. you can also use something like WireShark if you want to examine everything on the wire rather than set up a Proxy, as Fiddler does.

Elviselvish