Visual Studio 2017: Ending the line-ending wars

I write a lot of software in C# using Visual Studio 2017, and about a month ago, Visual Studio and git started arguing over how the .cs source files were formatted with respect to line endings.

We all know that UNIX uses just a newline (linefeed) to end each line, while DOS traditionally uses CR+LF to end lines, and Visual Studio is supposed to be squarely in the DOS world, but for whatever reason, I started getting these messages:

This would be understandable if the files were imported from some external project, but this one was created by Visual Studio itself. Huh? Accepting their offer to "fix" the file, I later commit this to my git repository and get another message:

PS> git commit Extensions.cs -m"Fixed some stuff"
warning: LF will be replaced by CRLF in Extensions.cs.
The file will have its original line endings in your working directory.

This has been going on for months, where fixing it for one messed it up for another, and I found no combination of knobs in either git or in Visual Studio that would MAKE IT STOP (or what made it start in the first place). It's been maddening.

It is not clear that my fix is a real fix, or if it's just a workaround, but I believe these issues stem from Visual Studio's inclusion of the Byte Order Mark at the start of each source file; this is a three-byte sequence (EF BB BF) that has something to do with Unicode encoding, but this confuses UTF-8, and I believe line-endings as well.

The fix is to use a .editorconfig file in the root of my project directory and tell it to use UTF-8 encoding and not UTF-8-with-byte-order-mark:

.editorconfig

...
[*.cs]
indent_size = 4
indent_style = space 
charset = utf-8
...

In my case, I closed and then opened the project, and future file saves stripped off the byte order mark, which ended the battle between VS and git.

Whew.

As an aside, I can't say enough about editorconfig, which lets you configure preferences that go with (and follow) a project and do not require everybody to tune their Visual Studio options every time they work on something new.

All projects should have an .editorconfig, and I'm grateful that VS2017 (and later) supporting it.