\r\n problem

[John B.]

Hi there,

I'm making a call to "DataSet.WriteXml(string fileName)" and the call is
converting all occurrences of "\r\n" to "\n" in the resulting file (for
string columns in each of my tables). Is there a way to write the "\r\n"
combination as-is or otherwise convert the "\n" back to "\r\n" automatically
when I later read it back in via "DataSet.ReadXml()"? Thanks very much.

 

[Morten Wennevik [C# MVP]]

Hi John,

I am unable to reproduse your issue. All my attempts at WriteXml correctly
produces the byte values 13 + 10 (\r\n) both between rows as well as string
values containing line breaks.

How do you know they are converted to \n? Are you sure they aren't \n to
begin with? Some controls are able to do linebreaks with just \n effectively
hiding the lack or \r.

 

[John B.]

Hi John,

I am unable to reproduse your issue. All my attempts at WriteXml
correctly
produces the byte values 13 + 10 (\r\n) both between rows as well as
string
values containing line breaks.

How do you know they are converted to \n? Are you sure they aren't \n to
begin with? Some controls are able to do linebreaks with just \n
effectively
hiding the lack or \r.

Thanks for the feedback. I just tried creating a new project and lo and
behold I get the same (expected) results as you. In my own app however the
problem persists which I've verified by inspecting my strings in the
debugger (just before "WriteXml()") and then examining the resulting file
afterwards (with a hex editor). This conversion is actually backwards in any
case. Normally a LF is converted to a CR/LF on output and back to a LF on
input (when conducting "text" vs "binary" mode processing in general). Note
that I also found at least one other posting where someone reported the same
problem but they got no response. I'll just have to look deeper now that I
see the problem isn't there in a new app. Perhaps some property was turned
on that affects this though not by me AFAIK. I'll let you know the outcome.
Thanks again.

 

[John B.]

Thanks for the feedback. I just tried creating a new project and lo and

behold I get the same (expected) results as you. In my own app however the
problem persists which I've verified by inspecting my strings in the
debugger (just before "WriteXml()") and then examining the resulting file
afterwards (with a hex editor). This conversion is actually backwards in
any case. Normally a LF is converted to a CR/LF on output and back to a LF
on input (when conducting "text" vs "binary" mode processing in general).
Note that I also found at least one other posting where someone reported
the same problem but they got no response. I'll just have to look deeper
now that I see the problem isn't there in a new app. Perhaps some property
was turned on that affects this though not by me AFAIK. I'll let you know
the outcome. Thanks again.

Ok, I couldn't find any problem so I reboot my machine (in desperation) and
now it's working. Go figure. I have a new (related) problem however. When I
read it back in using the "ReadXml(XmlReader xmlReader)" overload, it's
converting my "\r\n" to a "\n". IOW, it's performing the standard text mode
conversion mentioned in my last post but it doesn't do this if I simply
invoke "ReadXml(string fileName" instead (though I need the former overload
for its validation capabilities). I've been playing with the "XmlReader"
properties but can't find a way to eliminate this so far. Do you know how to
do this offhand? Thanks again.

 

[Ben Voigt [C++ MVP]]

Ok, I couldn't find any problem so I reboot my machine (in desperation)
and
now it's working. Go figure. I have a new (related) problem however. When
I read it back in using the "ReadXml(XmlReader xmlReader)" overload, it's
converting my "\r\n" to a "\n". IOW, it's performing the standard text
mode conversion mentioned in my last post but it doesn't do this if I
simply invoke "ReadXml(string fileName" instead (though I need the former
overload for its validation capabilities). I've been playing with the
"XmlReader" properties but can't find a way to eliminate this so far. Do
you know how to do this offhand? Thanks again.

XML is whitespace insensitive. You need to use entities when you have runs
of whitespace that must be preserved. I'm sure everyone is familiar with
using      for a run of spaces. While I'm not sure if
there are named entities for "\r\n", you should at least be able to use
"
". Actually, the fact that you care about "\r\n" vs "\n"
suggests that you want the binary data and not the platform-dependent
newline characters, so specifying the ASCII codes would be best.

 

[John B.]

XML is whitespace insensitive. You need to use entities when you have

runs of whitespace that must be preserved. I'm sure everyone is familiar
with using      for a run of spaces. While I'm not
sure if there are named entities for "\r\n", you should at least be able
to use "
". Actually, the fact that you care about "\r\n" vs
"\n" suggests that you want the binary data and not the platform-dependent
newline characters, so specifying the ASCII codes would be best.

Thanks for the info. Unfortunately my experience with XML is limited. In any
case, the data I'm writing to this file comes from an external source and
though I could manually parse these strings and replace "\r\n" as you
suggested, I assume there must be a cleaner way using some property or
whatever. The fact that I can read the CR/LF combination as-is via the other
overload (taking a single file name) pretty much confirms this. Since my
last post I also discovered the "XmlWriterSettings.NewLineHandling "
property but in light of the latter overload I don't see why I would need
this (if it's even relevant - I'm still investigating). Somewhere there must
be a property that disables this "text mode" conversion but it's not clear
what, at least not to an XML novice like myself. I've been spinning my
wheels for hours now in fact. In any case, thanks again.

 

[Dragan]

I have the same problem. I'm calling a web service that returns a sting.
The string contains \r\n. This value is converted to \n in the client
application. So I think this is a serialization problem.