2

I havve created a C# class representing an XSD using the XSD.exe tool. I use a valdiation code to check the consistency of the XML with the XSD. I got this working, but using another XML file causes exceptions.

The XML files are produced by an external program and I do not have access to the original code or to a published XSD.

During reading the XML during Deserialization I get an exception:

enter System.InvalidOperationException was unhandled

HResult=-2146233079 Message=Het XML-document (235, 17) contains an error.

The error is described as an attempt to convertt a string to a DateTime format (which cannt be a correct description).

I thougth (235,17) migt represent the location in the document, but this is not consistent with the call stack.

My question: can you help me with a good debugging strategy for this type of problems? I would like to know exactly at which line in the XML the exception occurs, but don't know how to do this.

RudolfJan
  • 91
  • 1
  • 11
  • Why can it not be a correct description of your issue? – Der Kommissar Apr 26 '15 at 16:15
  • `"(235, 17)"` are the line and character number on which the error occurs *[where the first line is line one](https://msdn.microsoft.com/en-us/library/system.xml.ixmllineinfo.linenumber%28v=vs.110%29.aspx) and [the first character is character one](https://msdn.microsoft.com/en-us/library/system.xml.ixmllineinfo.lineposition%28v=vs.110%29.aspx)*. I.e. the XML file starts at line 1 not line 0, and the first character on that line is character 1 not character 0. – dbc Apr 26 '15 at 18:55
  • See also here: [Troubleshooting Common Problems with the `XmlSerializer`](https://msdn.microsoft.com/en-us/library/aa302290.aspx). – dbc Apr 27 '15 at 20:21
  • It does not make sense to me that the exception reports a String to DateTime conversion, as I do not use DateTime datatypes in this application. So I am really confued. I will work on the issue today and see if all good advices help me. – RudolfJan May 02 '15 at 08:59
  • @RudolfJan - we might be able to help more if you post the entire `ToString()` output of the exception including the traceback. – dbc May 03 '15 at 20:15
  • Thank you, I managed to solve most issues, though sometimes things happen I still do not understand. I think I learned enough from all helpful answers to resolve the remaining problems. – RudolfJan May 10 '15 at 13:16

1 Answers1

5

Line and character numbers in the XML are reported to the exception message via the IXmlLineInfo interface, which XmlTextReader implements. Of note, both the line number and line position start with number one (and are zero only when not available).

Thus "(235, 17)" are the line number and position in the line (starting at one) at which the reader was positioned when the error was thrown. In most cases, that will be actual position in the XML file at which the error occurs. However, sometimes the XML Serializer will have advanced the reader to the next node before the error is thrown. From experimentation:

  1. If the XML is not well-formed, then the error will be where the line and position report.

  2. If the XML is well formed but an attribute value cannot be deserialized, then the attribute with the bad value will be where the line and position report.

  3. However, if the XML is well-formed and an element value cannot be deserialized, the XML reader will already have been advanced past the end of the element to the beginning of the next XML reader node (typically an element opening or closing), so the element causing the problem will be one one immediately before the reported location, possibly on the previous line.

  4. If the error is reported at (0, 0) then the reader was unable to begin parsing the XML. Likely problems include:

dbc
  • 104,963
  • 20
  • 228
  • 340
  • Thank you for your help and usefull clarification., I will be working on it today. – RudolfJan May 02 '15 at 09:00
  • Thank you for your help. I learned a lot during the last few days. The XMLs I use are complex and new data structures have been added over time, Old instances contain less data than new instances. The schemas are not available. I used xsd.exe to create the schemas, but the xsd.exe sets the type infor rather strict, e.g. a date value is created as UnsignedByte. For example, his results in errors when you try using a date with two digits. I used XMLSpy to validate a larger number of samples and I decided to accept that not all XML files will be deserialized properly at once. – RudolfJan May 10 '15 at 13:12
  • 1
    This question s from some time ago. I learned that in most cases the XDocument class is a much eaier way to work with XML. You avoid all hassle with XSDL files, especially if they are not available. – RudolfJan Feb 09 '18 at 08:24