Yes. Lutz Roeder's Reflector is one cool tool. I just found out using it that my latest article has some bad code in it because of reflector.
The article mentions that in order to write to a memory buffer instead f a file you can initialize a new XMLTextWriter object using a StringWriter object(which writes to a StringBuilder object in turn). In the article ,I discovered a problem that when writing to a string buffer using the StringWriter object initializer, the XML document that is created always turns out with an Encoding header of UTF-16 at the top. I couldn't figure out why.
I assumed it was something on my own system's configuration , so I pointed to a workaround for the problem - make the XMLTextWriter write directly to a file using a different constructor. That constructor allows you to specify the desired Encoding for that file, thus allowing you to specify UTF-8. I then wrote in the article that "You might get a UTF-16 encoding header" but I was wrong.
A quick peek inside the StringWriter's constructor using Reflector revealed the awful truth - The StringWriter initializes itself with a new UnicodeEncoding object by default, with no constructor available to change this decision. More so, the Encoding property of the StringWriter is read-only, thus you can't change it after creation.
So, this means (or am I way off base here) that whenever you'd use a StringWriter for an XMLTextWriter ctor, you would get a UTF-16 XML header. Always. No way to change that. That means you can't write an XML Document to a memory buffer as a UTF-8 encoded XML without going through some hoops.
Sure, I could use other classes in the framework but I shouldn't have to. Why should the Encoding property of the StringWriter be Read-Only?