c#: On Thu, 10 Apr 2008 19:50:09 -0700, Michael A. Covington =

[quoted text, click to view]
=

[quoted text, click to view]

There is no actual difference between the two. StreamReader _is_ a =

TextReader, and since that's what you instantiate in both cases, the typ=
e =

of the variable storing the reference to the instance is irrelevant.

[quoted text, click to view]

The StreamReader class inherits TextReader, so anything that uses a =

TextReader will work for a StreamReader. (In fact, TextReader is an =

abstract class, so you won't see any code examples at all that use =

something that's only a TextReader).

[quoted text, click to view]

You're definitely barking up the wrong tree (to continue the canine =

metaphor :) ).

As far as what it could be, that's hard to say. I think the first thing=
=

to confirm is whether you're actually dealing with an empty file, or an =
=

invalid file with data in it.

If you're dealing with an empty file, then my next guess would be that =

you're missing a Flush() or Close() or something somewhere in the =

generation of the file, causing it to be truncated (empty in this case).=
=

But that assumes that you're generating the file in the first place, and=
=

you didn't actually say anything that would support that assumption. So=
=

far all I know, that's an entirely irrelevant guess.

Alternatively, perhaps it's a timing issue (related to some buggy =

multithreaded code perhaps?) where one thread trying to read the file ge=
ts =

to it before some other thread finishes with it.

Actually, there are a large number of possibilities, so without having y=
ou =

narrow the problem down further, it's really hard to approach a solution=
.. =

At the very least, you're going to need to gather more data about what =

exactly you're looking at when this happens. You might consider =

delivering an instrumented build of your application that logs the data =
=

and operations it sees. Maybe even create a Stream and/or StreamReader =
=

class that you can insert between the respective objects that copies all=
=

of the data read out of the file to some other location that you can loo=
k =

at later. That way you can find out after the fact exactly what the =

XmlSerializer class saw.

A few of the users of my program are encountering an XmlException that looks
as if the XmlSerializer is seeing an empty file (error at line 0, position
0, root element missing).

I have a hunch the problem is that I was doing this:

StreamReader r = new StreamReader(filename);
XmlSerializer x = new XmlSerializer(...the type...);
....my object... = x.Deserialize(r);

when I should have been doing this:

TextReader r = new StreamReader(filename);
XmlSerializer x = new XmlSerializer(...the type...);
....my object... = x.Deserialize(r);

The documentation shows deserialization from a TextReader and from a Stream
but not from a StreamReader. Nonetheless, StreamReader worked 99.99% of the
time, and I have not been able to isolate the conditions under which people
were seeing an apparently empty file. They saw it very reproducibly, but
the same file, e-mailed to me and opened with the same program, worked
perfectly.

Am I following the right scent? What else could it be?

Thanks. I think an instrumented build is the way to go. I have never
reproduced the problem; the files look perfectly normal when the user
e-mails them to me; and I'm suspecting there's something weird about the
user's disk i-o situation.

In the latest release of the program I have made the error-checking a bit
more elaborate, but I probably need to go whole hog -- if there's a problem
reading the file in XML, then immediately read it as plain text and write it
in the log, so I can see what the program saw.