How to figure out exactly where the error is in the deserialization of WCF SOAP XML response?

Question

Apologies if this has been asked before but it seems I cannot find the answer.

I am trying to consume a SOAP Web Service using WCF. I've used Visual Studio 2015's Add Service Reference to add the service reference and generate all code.

The service call fails with the following CommunicationException error:

System.ServiceModel.CommunicationException : Error in deserializing body of reply message for operation 'XYZ'.
---- System.InvalidOperationException : There is an error in XML document (2, 979).
-------- System.FormatException : Input string was not in a correct format.

I understand the error; I understand that something (an element value, probably) in the XML response document cannot be deserialized according to what the svcutil's generated code dictates.

I am logging the XML response document. Also, I am comparing it with the SoapUI response and they both look identical.

SO how can I figure out exactly where the problem is in the XML document? Is there any method, technique or trick to step through the deserialization process and pinpoint the faulty bit? It is a rather long XML document ...

IMHO, at this point the WCF behaves like a black box that I cannot look inside it.

TIA,

Answer 1

Turn on WCF Trace:

https://learn.microsoft.com/en-us/dotnet/framework/wcf/diagnostics/tracing/configuring-tracing

Use the following application to view the results:

https://learn.microsoft.com/en-us/dotnet/framework/wcf/service-trace-viewer-tool-svctraceviewer-exe

Answer 2

Well, it seems one cannot really find exactly where such a deserialization error lies. Things get even worse if the service developer is not the same person as the service client developer.

In my case, the error was due to a mismatch of a data type between the service and the generated client code. The origin of the problem was the erroneous XSD. In order to find the error, I had to contact the service developer who managed to locate it.

Generally speaking, this is one of those things that make you feel you are losing control over your code; much like that point in a project when you want to look the source code of a library but you just can't because you don't own it. This is something all developers who decide to work on web services consuming project should be aware of.

Answer 3

For debugging, you can use Fiddler2 easily to capture any web traffic, including the full xml of a SOAP request/response (and it even handles SSL easily, unlike Wireshark)

For logging... I wish I knew. Sorry.

Also, dupe of In C#, How to look at the actual SOAP request/response in C#