Carriage return being stripped when using XSLCompiledTransform - simple XSL fix to prevent it

One of the most interesting and annoying parts about doing rewrites of .net 1.0 to .net 3.5 is discovering simple changes under the hood, have the potential to drive you nuts! XML serialization has been my personal cross as I do tasks such as transforming a message from XML to text using an XSLT. Now, you'd think that this would be simply changing from XslTransform to XslCompiledTransform. Unfortunately it's not that straight forward.


Now there are perfectly good reasons why Microsoft made the changes. They even kindly put up documentation for migration: Migrating From the XslTransform Class. So I rewrote the code, made some minor tweaks, checked the XSLT output against an XML payload. Perfect. And then I ran the code. Instead of getting a text file with an output like this:

Data Blah
Field 1: X
Field 2: Y
Field 3: Z
...

I got
Data Blah  Field 1: X  Field 2: Y  Field 3: Z

You might think, so what, the formatting is a bit screwed up. Sadly, the formatting is used by a secondary processor and the return carriages are the delimiters - part of which is a stored proc that I don't really want to change. 

So why is this happening? Well from what I can gather, it's all a part of the XmlReader and the way that it handles whitespace. Because this is from a few weeks ago, and is mainly notes to remind myself, I've forgotten most of the technical details (if I find my notes, I'll update this). Basically what ended up happening was that the XSL inserted text spaces such as #xD; or #xA; was effectively translating to a space when being read in. When the transformation happened to output the result as a text file through the XSLT, because the XML had been read in with spaces rather than Carriage Returns, the result ended up being one single line.

I played with much code, thought about rejigging the entire processing feed to insert and use a different delimiter character, and finally got a really stupidly simple thing to work. Rather than using just #xD;, I did a combination. So the XSL text became something like (note syntax may not be quite correct):


#xD; #xA;


I'm not sure why the two fields worked, when a singular one didn't, but hey, changing one line in an XSL rather than writing custom deserialiser is ok by me!

As a side note: #xD; is the same as  which is CR (Carriage return)
#xA; is the same as &a10, which is LF (Line feed)

From an XSL point of view, all of these values work, it's only when using the XMLSerializer in XMLReader which is used by XSLCompiledTransform that the transformations don't always work.