-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NewLine normalization on .NET Core #1401
Comments
Andy already knows this, but just for the sake of anyone reading this -- |
@AndyGerlicher can this issue be revisited? We've had multiple related issues reported on CLI (dotnet/cli#8147 and dotnet/cli-migrate#37). |
@peterhuene Andy's out sick today, but I think it's reasonable to try to move back to XmlTextReader; we already have hard .NET Core 2.1 dependencies. |
Related to #1340
In Full Framework, we do not normalize any line endings in a user's project file. To do this we had to use
XmlTextReader
. This behavior is legacy in all versions of MSBuild and should be preserved.In .NET Core,
XmlTextReader
is not available and there does not seem to be a way to not normalize EOL characters. This means doing any project file manipulation via the .NET Core version of MSBuild will result in all\r\n
characters normalized to\n
on Save.In the absence of built-in functionality to do this (it was taken out in .NET Core) the only way I can think of is trying to determine the 'right' EOL character on Load and replacing on Save. This could be:
\n
characters appear by itself, replace all NewLine characters with\n
(do nothing, this is all .NET Core supports).\r\n
on the way in,string.Replace()
on Save.Thoughts? We could try to be fancier and count the number of
\r\n
and if they appear more often than\n
use that? And of course if we do this for .NET Core, should we do the same in Full Framework MSBuild? I think not to preserve behavior, and I don't think there's a good solution here unfortunately.The text was updated successfully, but these errors were encountered: