[RESOLVED] WriteAllText encoding for LF/CR

If read a file using;

MyText.Text = System.IO.File.ReadAllText(sourceFile)

and later write a file using;

System.IO.File.WriteAllText(TargetFile, MyText.Text)

The Target file does not contain the LF/CR combination. I've tried qualifying the encoding with the extension System.Text.Encoding.....

e.g. System.IO.File.WriteAllText(TargetFile, MyText.Text,System.Text.Encoding.Ascii)

but I cannot find an encoding that generates the correct output in respect of the end of line return characters.

The output file looks fine in Wordpad, but because of the line breaks, it is one big crunched up lump when I open it in Notepad.

Any ideas?, it's driving me nuts....

You can use a streamwriter, and use the .writeline method in order to write each of the lines one by one... just a suggestion...

First off, LF/CR is for Windows where as other OSes may just use one. It isn't part of ASCII encoding, which is why it didn't do anything for you.

As already suggested, try using a Streamwriter. You could also use Environment.Newline if you want to just use the write() function of a Stream.

Also, if you're using a RichTextBox, it already has built in Saving and Loading methods to take care of this for you.

Thanks for the inputs but I dont quite understand. I want to read a users file, do a substitution and then rewrite the file. If I use;

MyText.Text = System.IO.File.ReadAllText(sourceFile)
and after the substitution write using;
System.IO.File.WriteAllText(TargetFile, MyText.Text)

I appear to lose the CrLF combination and just end up writing a Cr. So the LF is lost somewhere.

So I changed my code as suggested to do a stream read, append the incoming lines together (with a vbCrLf after each line) to rebuild the full text, then do the sub and then write out with a stream write.

But when I do this, it occurred to me that if the user did not have a CrLf combination in their file to start with, then they are now going to end up with it being added? Is this a problem or am I worrying unnecessarily?

I guess my question is also when I do a stream read, can I configure it such that the read will include any Lf or Cr characters that are present on the line?

The whole CrLf thing is a bit of a historical anomoly. In order to put a line break in a string in a .NET app you can use a Cr on its own, an Lf on its own or a CrLf combination, even though the "official" new line indicator on Windows is CrLf. If your file is originally written on a system that uses Cr as a new line indicator then it will not matter whether you use just Cr or CrLf as a new line indicator in the new file when it is read on Windows. It may be an issue on the other platform, although I'm not sure about that. For consistency, you could read the whole file and replace all lone Cr characters with CrLf combinations.

ok, thanks.

Well I've chickened out big time. Based on previous experience on a similar issue, I've added a "Windows" checkbox. If it is set, the write will write out LfCr at the end of each line, if it is not set, it will write the single return.

Since my usership could be porting files from any platform, I cannot make any assumptions about what will or will not be present in the input file.

So basically, it's now a new feature!