468,256 Members | 1,451 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,256 developers. It's quick & easy.

XML serialization of illegal character entities

Hello,

My wsdl.exe-generated, ASP.NET 1.1 web service pulls data from the local
Exchange 2003 store using CDO 2000 and returns it to consumers. CDO
occasionally returns (char)1, (char)5, and (char)12 from Exchange.
These are illegal characters in XML 1.0
(http://www.w3.org/TR/2004/REC-xml-20040204/#charsets), yet .NET still
serializes them into character entities, e.g.  . When .NET 1.1
consumers attempt to deserialize this, they receive an XmlException,
e.g. "'', hexadecimal value 0x05, is an invalid character. Line 1,
position 326." referring to the first appearance of an illegal character
entity. I don't believe I have altered the default serialization behavior.

According to an MSDN article, the XmlTextReader used by the ASP.NET Web
Services deserializer has its Normalization property set to false, which
causes the deserializer to throw the exception (See "Deserializing
Invalid XML" here:
http://msdn.microsoft.com/library/de...trblshtxsd.asp)

Is it possible to exchange strings with these characters using ASP.NET
1.1 Web Services? Have I configured something problematically? Is it
possible to change the XML deserializer behavior? Or is it possible to
configure the XML serializer to generate XML that will not cause this
behavior in the deserializer? Are there other relevant considerations
or recommendable techniques that could be helpful?

Thanks for any assistance.

--
Michael McGranahan
College Information Services, UCLA
Jul 11 '06 #1
0 1503

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

19 posts views Thread by Ian | last post: by
50 posts views Thread by The Bicycling Guitarist | last post: by
2 posts views Thread by Mike | last post: by
3 posts views Thread by bsagert | last post: by
reply views Thread by zattat | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.