I have some unit-tests that appear to be failing because they depend on the assumption that the line-break inside a locally-compiled here-document string should match Environment.NewLine.
I.e
var testString=@"a multiline
string";
//this fails
teststring.Should().Be("a multiline" + Environment.Newline +"string");
The real test is significantly more complicated and is being compiled and run on a machine I don't control so it's difficult to determine the exact cause but it does appear to boil down to this kind of mismatch.
The C# specification (see the section on string literals) says that "A verbatim string literal may span multiple lines" but doesn't actually say what line-break style will be used.
My working theory is that there's nothing magic about the line-breaks and that the compiler is just using whatever style happens to be in the source code file as it is checked out on the local machine. Therefore if someone has got their RCS line-translation wrong somewhere along the line it's possible that the string as compiled has Unix style line-endings even though it's being compiled on a Windows machine or vice-versa.
So my question is really:
Is there a formal description of how line-breaks within a multiline verbatim string literal should be encoded?
If not, is there an alternative explanation for why the test above might sometimes fail?
I am aware that Environment.NewLine is a runtime variable so the test could fail if compiled on one machine then run on a different one but in this case it appears it is being compiled and run on the same machine.