Applying autofixes uses wrong line endings / should honour .editorconfig

[dgeelen-uipath]

.editorconfig:

[*.cs]
end_of_line = lf

Example.cs:

namespace Bug
{
    public static class Example
    {
        public static int MissingNewLine(bool condition)
        {
            if (condition)
            {
                return 42;
            } // SA1513: Closing brace should be followed by a blank line
            return 0;
        }
    }
}

Applying the automatic fix for SA1513 (and probably a bunch of others, but this is the one where I tracked down the problem) inserts a CRLF (carriage return + line feed) combination, but the file uses LF only. In Visual Studio, you can observe the state of line endings for the current file in the bottom right corner of the file-editor pane. It should initially say LF, when the automatic fix is applied it will switch to MIXED instead:

The next time the file is opened (but not immediately when the problem is introduced!), Visual Studio will complain about mixed line endings, and suggest to 'normalize' the line endings (using the wrong default option, of-course):

The root-cause is probably because the fixer appears to use a hard-coded CRLF (SyntaxFactory.CarriageReturnLineFeed) rather than the currently configured line-end character.

[bjornhellander]

There are about 40 places in the code fixers that use SyntaxFactory.CarriageReturnLineFeed directly. Do you see any problem with replacing them with code that creates trivia from GetOption(FormattingOptions.NewLine, LanguageNames.CSharp), @sharwell?

[sharwell]

For SA1513, I'd rather update it to match the newline already at the end of the line where the fix is being applied. Existing uses of FormattingOptions.NewLine are potentially problematic because they look at workspace options instead of focusing on the current document.