I’m trying to load an XML file but getting a runtime error: “Input string was not in the correct format”
There’s no indication as to where. The trace (below) shows it’s entirely within XML deserialization.
I’ve run the datafile through four different XML validators and they all think it’s fine. Is there any way to track down what is causing the parser to go?
You should provide some code and a short XML example.
Apparently, one value does not have the expected format, i.e. it might be saved as some alphanumeric string (or empty string) and cannot be parsed in order to get the integral value.
Well, does the XML validator use a scheme (xsd) in order to validate the document’s layout, data types and constraints? Or did you just run a “syntax” check (e.g. tags are properly opened / closed).
I asked for code and a sample file.
I also stated why this could still fail even though validators tell you it’s valid.
You cannot just post a stacktrace and expect people to offer solutions.
Exceptional behaviour occurs to either uncontrollable conditions or faults in code/files. We don’t know anything about the one or the other.
var stream = new FileStream(path, FileMode.Open);
Brain items = serializer.Deserialize(stream) as Brain;
Pretty boilerplate; the rest all comes from Mono, as the (not very useful) stack trace shows.
The input file is 340K, and the error is somewhere in there. Not practical to post. The exact error is “Input string was not in the correct format” which is not a tag matching or XSD error, it’s strictly a syntax error. I also tried loading the file in a few different IDEs, but none of them found any problems either.
That’s a start.
The stack trace is usually very useful, but only if enough information is provided.
What I wanted to point out with the comment about tags etc. is, that it wasn’t quite clear whether the ‘validation’ had been done with a scheme definition or not since it does make a difference doing the one or the other.
Anyways, strictly speaking, it’s not a syntax error (I had already taken note of the exact error message, don’t worry).
If you used an XSD for validation it has either got some loose constraints or your data structure’s field types do not match the corresponding constraints, which means that they’re more restrictive.
The question would be which side holds truth.
Is the XSD correct, you would not be allowed to assume the value will always be a valid integer so you’d need to change your data type. However, if it must be an integer, the XSD is not restrictive enough.
The error which happens during the deserialization is pretty clear, hence the example in the first post.
There’s a value somewhere in that file which shall be parsed and assigned to an integer field of one of your C# types, but it’s got a wrong format which means (for example) an attribute’s or elements value is allowed to be alphanumeric by the definition of the XSD (if there is some) or is simply empty (hence succesful validation), whereas the deserializer expects it to be a valid character sequence for integer parsing.
One way would be to compare the XSD (if there is one) with your defined data types. The field types should (more or less) match the type constraints.
*edit
Also possible, but less likely is that it’s some kind of encoding issue. Shouldn’t be the case though since it’s an integer-parse error.
Thank you very much, Suddoha, that did it.
I didn’t have an XSD because these datafiles are actually exported from another piece of software. They’re keeping things close, so there aren’t any details about exactly what’s in the files. I was building up descriptions based on looking through some of the data.
And that’s where the rub was. Turns out one of the fields was an integer only 99.5% of the time. No way to tell when that .5% occurs. Since it was a parseInt error, I went through each one of their numeric fields with regex searches until I finally found one of the departures, and that gave me the mechanism for finding and altering each one.
Those departures are pretty deeply buried, no way to find them without some tedious digging. But thanks to your comments I got the impetus on how to track down what was going on, and now I can load the data from this other software, and that critical path is rolling. Thanks again.