Buffer bug with XmlTextReader

[Kjeld]

My scenario:
I'm using an XmlTextReader to Deserialize serveral classes from a single xml
document. Every class i pass the source stream, containing the xml.
Each class subsequently creates an XmlTextReader object with that stream as
input.
However, the second class that performs this operation cannot start reading
at position X, because the first instance of XmlTextReader advanced the
position in the stream to the end of the stream.
This is in contrast with the BinaryReader class, which does not advanced
stream.Position any further then needed.
Is the XmlTextReader class buffering input? This seems to be unwanted
behavior.

Sample:
Here is a sample xml document:
<CLASS1>
<CLASS2>class 1 text</CLASS2>
<CLASS3>class 2 text</CLASS3>
</CLASS1>

Sample implementation in C#:
// image code here to put this xml in a stream object

XmlTextReader reader1 = new XmlTextReader(s ourceStream);
reader1.Read()
//at this point, reader1.Name == "CLASS1"

XmlTextReader reader2 = new XmlTextReader(s ourceStream);
reader2.Read() // <-- this call failes with the XmlExcpetion 'There is no
root element'. In my opinion the call is valid and reader2.Name should be
"CLASS2"

When I check the value of sourceStream.Po sition, i conclude that the first
reader has completely read the source stream.

Can I solve this or is it a bug?

[Oleg Tkachenko [MVP]]

Re: Buffer bug with XmlTextReader

Kjeld wrote:
[color=blue]
> I'm using an XmlTextReader to Deserialize serveral classes from a single xml
> document. Every class i pass the source stream, containing the xml.
> Each class subsequently creates an XmlTextReader object with that stream as
> input.[/color]

Why don't you pass XmlTextReader instead of bare stream?

--
Oleg Tkachenko [XML MVP, MCAD]

http://www.xmllab.net

http://blog.tkachenko.com

[Kjeld]

Re: Buffer bug with XmlTextReader

Because my object should serialize to XML when debug mode is set in the
app.config (a custom app setting). The object should serialize to a binary
stream when not in debuggin mode (to optimize performance).
All my classes implement I<productname>S erialize which defines a Serialize
and a Deserialize method, taking a System.IO.Strea m object as input.

Do you think we are talking about a bug here, or a feature I do not yet know
the reason for? Is there a workaround?
I think I could pass an object to my methods instead of a stream object and
cast the object to whatever writer I'm using. This would solve the
'state/buffer' issue but pollute my interface.

"Oleg Tkachenko [MVP]" schreef:
[color=blue]
> Kjeld wrote:
>[color=green]
> > I'm using an XmlTextReader to Deserialize serveral classes from a single xml
> > document. Every class i pass the source stream, containing the xml.
> > Each class subsequently creates an XmlTextReader object with that stream as
> > input.[/color]
>
> Why don't you pass XmlTextReader instead of bare stream?
>
> --
> Oleg Tkachenko [XML MVP, MCAD]
> http://www.xmllab.net
> http://blog.tkachenko.com
>[/color]

[Oleg Tkachenko [MVP]]

Re: Buffer bug with XmlTextReader

Kjeld wrote:
[color=blue]
> Do you think we are talking about a bug here, or a feature I do not yet know
> the reason for? Is there a workaround?[/color]

I don't think that's a bug. That's by design.
As a workaround you can have record length or some end-of-record marker
somewhere on the stream and don't let XmlTextReader read more than
needed (either buffer record before parsing - as it's debug anyway or
override Stream to count bytes read).

--
Oleg Tkachenko [XML MVP, MCAD]

http://www.xmllab.net

http://blog.tkachenko.com