3

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,

dpant
  • 1,622
  • 19
  • 30
  • So what is in the XML document at line 2 position 979? – har07 Mar 18 '17 at 23:28
  • @har07 Here is the 2nd line of the response as logged by the WCF message inspector using the `AfterReceiveReply` method: `` ... So much for the (line,position) coordinates :( – dpant Mar 19 '17 at 14:30

3 Answers3

1

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.

dpant
  • 1,622
  • 19
  • 30
  • Their WCF soap client generator buries and hides its generated code deep inside your solution because Microsoft knows exactly how to write your client. If you wind up finding the hidden Reference.cs file, it will show you why they don't want you seeing it. – ATL_DEV Oct 09 '18 at 21:33
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

ATL_DEV
  • 9,256
  • 11
  • 60
  • 102
0

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#

Community
  • 1
  • 1
Mohammad
  • 2,724
  • 6
  • 29
  • 55
  • No, thanks, no, no, no. I can already log and view the request and response messages. As far as I can tell, the response XML document looks good and is identical to the one I get when I test with SoapUI. Nevertheless, the XML does not get deserialized by WCF. HOW can I find out which part of it is causing trouble? – dpant Mar 19 '17 at 13:59
  • please post the entire response and the wsdl file so we can help you. – Mohammad Mar 20 '17 at 05:41