views:

1202

answers:

3

I am using C# .Net 2.0 to write a webservices client. The server's soap implementation is tested and is pretty solid. gSoap/C++ applications had no problem reading the responses. However the .Net implementation complains "There is an error in XML document" while calling one of the methods. Similar responses recieved from the server were happily processed by the xml parser.

Looks like to me the MSXML parser (I hope thats the one .Net is been using) is a very unforgiving parser.

I have no control over the server. Some how I have to work around this problem. So, I was thinking of writing a SoapExtension as describe here

So my question is, can I hook a parser before Deserialize stage and completely bypass the Deserialize stage.

And above all, how do i instruct the SOAP stub to use my extended class ?

+1  A: 

First of all I'd grab a snapshot of the failing XML in the Deserialise stage to try and diagnose the problem.

You can hook your soap extension into your client app without recompiling. Just add:

<webServices>
    <soapExtensionTypes>
     <add type="DebugTools.SOAP.SOAPTrace.SoapTraceExtension, DebugTools.SOAP" 
               priority="0" group="High"/>
    </soapExtensionTypes>
</webServices>

DebugTools.SOAP.SOAPTrace is the namespace of the SoapTraceExtension
DebugTools.SOAP is the name of the assembly containing the soap trace code.

to your app.config or web.config file.

It would be handy if you could paste in the complete exception with stack trace. There may be something really obvious. Also, if possible the WSDL for the web service, that would be very useful.

Cheers
Kev

Kev
A: 

If you would like to step through the serialise/deserialise code, you can use a tool called SGen. This comes with VS in the SDK, and is used as follows:

  1. Compile the app using the normal VS-generated (or wsdl.exe generated) proxy classes (These are usually hidden and are in a file called Reference.cs

  2. Drop to the Visual Studio cmd prompt, and open the Debug/Release folder (i.e. the folder the exe has been compiled to)

  3. Type the following at the cmd prompt (replacing TheApplicationName with yor app's name): SGEN /keep TheApplicationName.exe

You will now see a number of files have been created. Delete all the generated files except for the .cs file (including the dll it creates)

Move the .cs file to the source folder, and include it in your project.

Add the following attribute to your Reference.cs :

[XmlSerializerAssembly()]

You can now step through the actual serialising and deserialising code to find the actual problem (and if there's no other way to fix the problem, you can alter this generated code as required)

Chris Anderson
A: 

BTW, .NET does not use MSXML. It has its own implementation. The performance would be horrible if XmlReader were calling out to MSXML for every Read call.

John Saunders