问题描述
今天，我遇到了一个有趣的问题:即使在使用相同配置的情况下，我的测试在构建机器上也能正常工作时，在构建机器上的测试始终失败.当我查看故障转储中Assert.AreEqual输出的差异时，看不到任何差异.经过一番调查，我发现测试用例源代码中的逐字字符串(跨越多行)在我的机器上使用CRLF，但是在构建机器上使用LF，从而导致该字符串与生成的字符串进行比较字符串失败.罪魁祸首是两个系统上的Git设置不一致，构建系统会自动将CRLF序列转换为LF.
I ran into an interesting problem today where my tests were failing consistently on the build machine when they worked just fine on my machine even using the same configuration. When I looked at the differences output by Assert.AreEqual in the failure dump, I couldn't see anything different. After a bunch of investigation, I came to find out that the verbatim string in the test case source code (which spanned multiple lines) was using CRLF on my machine, but using LF on the build machine, causing comparisons of that string with a generated string to fail. The culprit turned out to be inconsistent Git settings on the two systems, with the build system automatically converting CRLF sequences to just LF.
C#规范是否说明了应如何解释逐字字符串中的换行符(也许使用Environment.Newline或至少是一些一致的东西)?这似乎是一个问题，可能会以非常难以诊断和修复的方式(特别是使用.NET Standard)咬伤很多人.例如，如果您有一个.NET Standard项目，并且在Linux和Windows上都有团队成员，那么这很可能会伤及Linux团队成员或Windows团队成员.
Does the C# specification say anything about how line breaks in verbatim strings should be interpreted (perhaps using Environment.Newline, or at least something consistent)? This seems like a problem that could bite lots of people in very hard to diagnose and hard to fix ways, especially with .NET Standard. For example, if you have a .NET Standard project, and have team members on both Linux and Windows, this is likely to bite either the Linux team members or the Windows team members.
推荐答案
规范未解决此问题:
由于行尾没有例外，因此您将获得源文件中使用的任何行尾.如您所知.
Since no exception is made for line endings, you get whatever line endings were used in the source file. As you found out.
这篇关于C#逐字字符串换行符:CRLF，CR或LF?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！