A little background.
This is a VB.Net client application , and it uses a web reference to a web
service, which has been properly refreshed.
My app takes collections of two serializable objects, and serializes them to
a XMLDocument object. The serializer uses Chris Lovett's XMLNodeWriter.d ll to
write directly to the XMLDocument.
XMLDocument.Doc umentElement is passed to the Web method which takes an
XML.XMLNode parameter. (Originally the XML was passed as a string. This was
changed based upon a GotDotNet thread I read, in which Dare Obasanjo states
that using an XML.XMLNode object is recommended for passing XML to a
webservice. The XML string also produced a slightly different server parsing
error).
Intermittently, the following error is sent up the call stack when making
the call from a client's machine. We have isolated the exception to specific
object instances, and can now reproduce the following.
System.Web.Serv ices.Protocols. SoapException: Server was unable to read
request. --> There is an error in XML document (1, 754). --> The '<'
character, hexadecimal value 0x3C, cannot be included in a name. Line 1,
position 1025.
at
System.Web.Serv ices.Protocols. SoapHttpClientP rotocol.ReadRes ponse(SoapClien tMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Serv ices.Protocols. SoapHttpClientP rotocol.Invoke( String
methodName, Object[] parameters)
First, is this actually a server side exception, or will the proxy code
generated by the web reference throw this exception? (Confusing since the
text of the exception includes : Server was unable to read request.)
Second, after encountering this exception I save the contents of the
XMLDocument. The client sends me this XML file, and loading this file into an
XMLDocument object, I can successfully execute the web service while
stepping through the client in the VS.Net IDE. One difference is that my
client's computer does not have the Framework 1.1. SP1 applied, and I do. I
googled the fixes introduced by SP1, but saw nothing related to this problem.
Did I miss something?
Third, the serializable classes are pretty straightforward . Their are two of
them. They inherit from base classes which contain only public fields of
native(?) types (String,Integer etc.) . They also contain arraylists of other
objects(email, address etc.) which are also simple classes containing only
public fields of native types. I use the XmlInclude attribute to include
these types. Am I missing a known bug in XMLSerializatio n which would explain
the exception?
Fourth, as I stated, we now have it isolated to a few different specific
object instances. What is frustrating is that the serialized XML can be
successfully saved at the time of the exception. Inspecting the XML, it is
well-formed. Could the XMLDocument be doing something under the hood when
saving that corrects the problem? Again, the DocumentElement property of the
XMLDocument is passed as the argument. You would think this would be an exact
replica of what would be saved to file.
Finally, if this is truly a server side exception, I am assuming it is
occuring in the .Net runtime before ever reaching the actual web method code.
What are my options for sniffing this low level?
Any contributions would be greatly appreciated.
Matthew
This is a VB.Net client application , and it uses a web reference to a web
service, which has been properly refreshed.
My app takes collections of two serializable objects, and serializes them to
a XMLDocument object. The serializer uses Chris Lovett's XMLNodeWriter.d ll to
write directly to the XMLDocument.
XMLDocument.Doc umentElement is passed to the Web method which takes an
XML.XMLNode parameter. (Originally the XML was passed as a string. This was
changed based upon a GotDotNet thread I read, in which Dare Obasanjo states
that using an XML.XMLNode object is recommended for passing XML to a
webservice. The XML string also produced a slightly different server parsing
error).
Intermittently, the following error is sent up the call stack when making
the call from a client's machine. We have isolated the exception to specific
object instances, and can now reproduce the following.
System.Web.Serv ices.Protocols. SoapException: Server was unable to read
request. --> There is an error in XML document (1, 754). --> The '<'
character, hexadecimal value 0x3C, cannot be included in a name. Line 1,
position 1025.
at
System.Web.Serv ices.Protocols. SoapHttpClientP rotocol.ReadRes ponse(SoapClien tMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Serv ices.Protocols. SoapHttpClientP rotocol.Invoke( String
methodName, Object[] parameters)
First, is this actually a server side exception, or will the proxy code
generated by the web reference throw this exception? (Confusing since the
text of the exception includes : Server was unable to read request.)
Second, after encountering this exception I save the contents of the
XMLDocument. The client sends me this XML file, and loading this file into an
XMLDocument object, I can successfully execute the web service while
stepping through the client in the VS.Net IDE. One difference is that my
client's computer does not have the Framework 1.1. SP1 applied, and I do. I
googled the fixes introduced by SP1, but saw nothing related to this problem.
Did I miss something?
Third, the serializable classes are pretty straightforward . Their are two of
them. They inherit from base classes which contain only public fields of
native(?) types (String,Integer etc.) . They also contain arraylists of other
objects(email, address etc.) which are also simple classes containing only
public fields of native types. I use the XmlInclude attribute to include
these types. Am I missing a known bug in XMLSerializatio n which would explain
the exception?
Fourth, as I stated, we now have it isolated to a few different specific
object instances. What is frustrating is that the serialized XML can be
successfully saved at the time of the exception. Inspecting the XML, it is
well-formed. Could the XMLDocument be doing something under the hood when
saving that corrects the problem? Again, the DocumentElement property of the
XMLDocument is passed as the argument. You would think this would be an exact
replica of what would be saved to file.
Finally, if this is truly a server side exception, I am assuming it is
occuring in the .Net runtime before ever reaching the actual web method code.
What are my options for sniffing this low level?
Any contributions would be greatly appreciated.
Matthew