How to open XmlReader from string?

[Katit]

I have string with XML, need to read it using XmlReader. I don't see
any way to feed string variable in there.
How it's done?

Thanks!

 

[Jon Skeet [C# MVP]]

I have string with XML, need to read it using XmlReader. I don't see
any way to feed string variable in there.
How it's done?

Use XmlReader.Create passing in a StringReader created from the string.

 

[Gina_Marano]

I found this on google:

XmlTextReader reader = new XmlTextReader(new
MemoryStream(ASCIIEncoding.Default.GetBytes(myXMLstring)));

I am attemting this as we speak.

~GINA_M~

 

[Jon Skeet [C# MVP]]

I found this on google:

XmlTextReader reader = new XmlTextReader(new
MemoryStream(ASCIIEncoding.Default.GetBytes(myXMLstring)));

I am attemting this as we speak.

That's awful code:

1) Using ASCII (which is what it *looks* like it would do) would be a
bad idea to start with - any non-ASCII characters would be lost
2) Using the platform default encoding (which is what it *actually*
uses) is a bad idea for the same reason
3) It's doing a conversion for no reason

StringReader is safer, simpler and more efficient.

 

[Aneesh Pulukkul[MCSD.Net]]

That's awful code:

1) Using ASCII (which is what it *looks* like it would do) would be a
bad idea to start with - any non-ASCII characters would be lost
2) Using the platform default encoding (which is what it *actually*
uses) is a bad idea for the same reason
3) It's doing a conversion for no reason

StringReader is safer, simpler and more efficient.

One more thing, while dealing with streams, be sure that we close/
dispose the stream objects properly else we'll get he access denied/
file is in use by another process issues.

new XmlTextReader(new
MemoryStream(ASCIIEncoding.Default.GetBytes(myXMLstring))); // Create
a memory stream object and dispose it.

I would suggest using the 'using' scope. E.g.

using (FileStream fStream = new FileStream(filePath,
FileMode.Create, FileAccess.Write))
{
using (StreamWriter writer = new
StreamWriter(fStream))
{
writer.WriteLine(myList.ToString());
writer.Close();
}
fStream.Close();
}

 

[Jon Skeet [C# MVP]]

One more thing, while dealing with streams, be sure that we close/
dispose the stream objects properly else we'll get he access denied/
file is in use by another process issues.

new XmlTextReader(new
MemoryStream(ASCIIEncoding.Default.GetBytes(myXMLstring))); // Create
a memory stream object and dispose it.

I would suggest using the 'using' scope. E.g.

While I would normally agree with you, there are no files involved here
in the first place - with both MemoryStream and StringReader, the only
resources involved are in memory.

When using XmlReader, I believe that closing the XmlReader will close
any streams it's been passed.

 

[Nicholas Paldino [.NET/C# MVP]]

If you call the overload of Create on XmlReader that takes just a
TextReader implementation, then no, the XmlReader will not close the
underlying reader. You have to pass an XmlReaderSettings to the Create
method setting the CloseInput property to true.

It's probably not the worst idea in the world though to use it in a
using statement, even though you are using a StringReader. By skipping it
(kind of like not calling Dispose on the DataSet) you are coding based on an
implementation detail, which as we all know, is bad (as a general statement,
of course, there are instances where you are forced to code against
implementation details).

 

[Jon Skeet [C# MVP]]

If you call the overload of Create on XmlReader that takes just a
TextReader implementation, then no, the XmlReader will not close the
underlying reader. You have to pass an XmlReaderSettings to the Create
method setting the CloseInput property to true.

Ah - thanks for clearing it up.

It's probably not the worst idea in the world though to use it in a
using statement, even though you are using a StringReader. By skipping it
(kind of like not calling Dispose on the DataSet) you are coding based on an
implementation detail, which as we all know, is bad (as a general statement,
of course, there are instances where you are forced to code against
implementation details).

I think in this case I'd see how easy it was to do. It may be
relatively tricky to wrap a using statement round the lifetime of the
XmlReader, given that you certainly shouldn't close the stream just
after creating the reader.

Agreed on the general point of not coding to implementation though.