I try to serialize an exception using the SoapFormatter, but this is a little
bit problematic. The MethodInfo tag of the serialized exception contains &x00
characters (ASCII 0x00) in its serialized data. When the data is deserialized
on the client side the SoapHttpClientP rotocol.ReadRes ponse uses an
XmlTextReader with Normalization switched on. In that case the &x00 character
is not valid and results in the following XmlException:
System.Xml.XmlE xception: '\0', hexadecimal value 0x00, is an invalid
character. Line 1, position 398.
at System.Xml.XmlS canner.ScanHexE ntity()
at System.Xml.XmlT extReader.Parse BeginTagExpandC harEntities()
at System.Xml.XmlT extReader.Read( )
at System.Xml.XmlL oader.LoadChild ren(XmlNode parent)
at System.Xml.XmlL oader.LoadEleme ntNode()
at System.Xml.XmlL oader.LoadCurre ntNode()
at System.Xml.XmlL oader.ReadCurre ntNode(XmlDocum ent doc, XmlReader reader)
at System.Xml.XmlD ocument.ReadNod e(XmlReader reader)
at
System.Web.Serv ices.Protocols. SoapHttpClientP rotocol.ReadSoa pException(XmlR eader reader)
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)
I don't know think that the actual problem is that the SOAP message parsing
uses a normalized reader, but the MethodInfo is serialized using '\0' as
seperators. I checked the serialization using the .NET Reflector tool and it
System.Exceptio n is using this character on purpose. It is a bit weird that
the SoapFormatter can create serialized XML data that cannot be parsed on the
client side.
I can solve this problem by using a binary serialization and store the
BASE-64 data in the detail node, but this makes my SOAP messages less
readable. I really liked the idea to serialize exceptions via the Detail node
(I regenerate them on the client). I use a workaround right now, but I am not
quite happy with it. Can anyone comment to this issue?
--
Greetings,
Ramon de Klein
bit problematic. The MethodInfo tag of the serialized exception contains &x00
characters (ASCII 0x00) in its serialized data. When the data is deserialized
on the client side the SoapHttpClientP rotocol.ReadRes ponse uses an
XmlTextReader with Normalization switched on. In that case the &x00 character
is not valid and results in the following XmlException:
System.Xml.XmlE xception: '\0', hexadecimal value 0x00, is an invalid
character. Line 1, position 398.
at System.Xml.XmlS canner.ScanHexE ntity()
at System.Xml.XmlT extReader.Parse BeginTagExpandC harEntities()
at System.Xml.XmlT extReader.Read( )
at System.Xml.XmlL oader.LoadChild ren(XmlNode parent)
at System.Xml.XmlL oader.LoadEleme ntNode()
at System.Xml.XmlL oader.LoadCurre ntNode()
at System.Xml.XmlL oader.ReadCurre ntNode(XmlDocum ent doc, XmlReader reader)
at System.Xml.XmlD ocument.ReadNod e(XmlReader reader)
at
System.Web.Serv ices.Protocols. SoapHttpClientP rotocol.ReadSoa pException(XmlR eader reader)
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)
I don't know think that the actual problem is that the SOAP message parsing
uses a normalized reader, but the MethodInfo is serialized using '\0' as
seperators. I checked the serialization using the .NET Reflector tool and it
System.Exceptio n is using this character on purpose. It is a bit weird that
the SoapFormatter can create serialized XML data that cannot be parsed on the
client side.
I can solve this problem by using a binary serialization and store the
BASE-64 data in the detail node, but this makes my SOAP messages less
readable. I really liked the idea to serialize exceptions via the Detail node
(I regenerate them on the client). I use a workaround right now, but I am not
quite happy with it. Can anyone comment to this issue?
--
Greetings,
Ramon de Klein