\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.

[=?Utf-8?B?TW9ydGVuIFdlbm5ldmlrIFtDIyBNVlBd?=]

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.

--
Happy Coding!
Morten Wennevik [C# MVP]
"John B." wrote:

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.

[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.

[=?Utf-8?B?RHJhZ2Fu?=]

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.