Visual Studio 2017 support

[ForNeVeR]

Now, after VS2017 release, we can see what have been done there, and what haven't been done.

I have been using EditorConfig for Visual Studio to consistently set the following properties on my projects:

[*]
charset = utf-8 # that means without BOM
indent_style = space
indent_size = 4
insert_final_newline = true
trim_trailing_whitespace = true

VS2017 doesn't support charset = utf-8 (and forces the BOM all the way), nor insert_final_newline neither trim_trailing_whitespace, and that causes mess in my sources. The kind of mess I'd like to exterminate.

I think that embedded EditorConfig support in VS2017 isn't very useful in its current state, and I'd like the plugin to be resurrected and released for VS2017.

[Denis535]

Are embedded EditorConfig plugin and this plugin different plugins?

[jednano]

Yes, quite.

[enlight]

Supposedly insert_final_newline and trim_trailing_whitespace are supported in the VS2017 15.3 (currently in preview). Alas I've discovered after some frustration that VS2017 15.2 also doesn't support tab_width, but at least that's easy to get around by setting indent_size instead.

[mihaipopescu]

I'd adhere also to a way to disable VS2017 "native" support (or for Microsoft just to fix it) and put the extension back on the marketplace. We're waiting for utf-8 bugfix to be available in VS2017.

[whyleee]

Another problem with VS2017 that it doesn't support end_of_line = lf correctly - it always creates files with CRLF endlines 😕

[mihaipopescu]

really? for any type of file? are you sure it's not your repo setting who is messing with eol's?

[bkaradzic]

MS VS2017 support is really jenky (at least with C++ projects). I just switched to VS2017 from VS2015 and EditorConfig is mixing tabs/spaces. It seems it's getting confused with multiple .editorconfig that have different settings. This worked fine with plugin in previous versions of VS.

[KindDragon]

Please report this bug to them with a description your .editorconfig files and where they stored https://developercommunity.visualstudio.com/spaces/8/index.html

[bkaradzic]

Uh... I'm reporting it here because I don't believe MS is capable of maintaining it. Old plugin just worked fine, no issues for years and multiple versions of VS, and then MS takes it over and breaks it. Obviously they were incompetent to integrate fully working VS plugin into VS.

[KindDragon]

But no one maintains this extension anymore...

[mihaipopescu]

Then let's just close the issue. It's a Vistual Studio issue and we should open it on their side.

[binki]

@mihaipopescu @whyleee References for the end_of_line=lf issues:

• Typing /// in C# file results in CRLF being used for the lines with the generated comment: https://github.com/dotnet/roslyn/issues/23143 (originally https://developercommunity.visualstudio.com/content/problem/144281/comment-templates-doesnt-respect-end-of-line-lf-in.html)
• Creating a non-C# file from a template, e.g. an XML file, results in the file being in CRLF mode even though end_of_line=lf but insert_final_newline=true adds an LF instead of CRLF to the end of the file, creating a mixed file: https://developercommunity.visualstudio.com/content/problem/277772/editorconfig-bad-interaction-bewteen-end-of-linelf.html (originally https://github.com/dotnet/roslyn/issues/28027)

[mihaipopescu]

I just tested in VS2017 v15.8.9:

[*]
charset = utf-8                  # FIXED
insert_final_newline = true      # FIXED
trim_trailing_whitespace = true  # NOT FIXED

[ziriax]

I just tested in VS2017 v15.8.9:

[*]
charset = utf-8                  # FIXED
insert_final_newline = true      # FIXED
trim_trailing_whitespace = true  # NOT FIXED

end_of_line = lf # NOT FIXED

[KinsonDigital]

I am currently getting different things that are not working for me as well.

csharp_space_after_comma = true:warning # NOT WORKING

[jednano]

@KinsonDigital that's not a supported EditorConfig rule.

[binki]

That looks like one of those things which a VS addon will read from the .editorconfig file. It’s exemplified by https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/998420eee298ccb8fa7b0fd1550bb106d3290b0a/.editorconfig#L48 . In this case, they’re using .editorconfig as a config file for their tools with the assumption that your editor is going to use a roslyn-powered language service which can be replaced with the latest version. It looks like it is defined here: https://github.com/dotnet/roslyn/blob/51638c7f7adf70c72c80eae27732e0337de3ccca/src/Workspaces/CSharp/Portable/Formatting/CSharpFormattingOptions.cs#L221.

[ocornut]

Using Visual Studio 2019 (Version 16.4.5) and it still doesn't get trim_trailing_whitespace right (and perhaps others..) or maybe I'm not able to make it work with VS2019 (tried adding .editorconfig file to project, restarting, etc.). Other settings such as indent_size DO work. What a mess.

PS: By which I mean, for whatever it is worth, considering VS inability to get this working it would be nice to keep this plugin working with VS2017 and VS2019 instead.

EDIT As it happens,VS brand of support for trim_trailing_whitespace is to trim a line only when pressing enter on it (or reformatting the whole document) so it eluded my tests. I find the behavior of this plugin more desirable but I guess VS does have (different flavor of) support for this feature and minimize the need for a plugin.

EDIT.2 Should clarify that I do understand why VS is doing it this way. For typical OSS contribution is may be favorable to iteratively update lines only when changed. I wish there was an option or that the EditorConfig specs provided explicit settings as to which behavior to adopt.

[ffes]

There is an open bug report at: https://developercommunity.visualstudio.com/content/problem/953937/bug-editorconfig-trim-trailing-whitespace-only-app.html

The EditorConfig specification is clear about how trim_trailing_whitespace should behave and clearly VS2019 does not behave this way. They indeed only trim trailing whitespaces when you press Enter at the end of a line, but trailing whitespaces can obviously occur in many more ways.

Should clarify that I do understand why VS is doing it this way.......

But when you edit a file with another editor that does follow the specs, those whitespaces will get deleted anyway. So it eventually will result in changes to the file. And know that when you set that setting in your .editorconfig you explicitly ask for that behavior, so those edits are legitimate.

In that developers community post it should be made more clear they don't follow the specs. As EditorConfig community we should extend and upvote that post.

[ifarbod]

Bump, after all these years, VS' editor config support is still lackluster, I'd like to revive this plugin, in fact I've been using it but I'm annoyed by the yellow deprecation warning.

Here's my failed attempt. I'm very unfamiliar with the codebase and VSSDK, so I would appreciate some pointers from the devs.

[jgwinner]

Just ran into this plugin, and was really happy until it turns it that it won't load with modern version of VS.

I'm also very frustrated that the native .editorconfig WILL NEVER be according to spec.

Apparently MS honestly believes that trimming white space should only be done "on the current line" not every line in the file.

So please support VS 2019 and VS 2022.

[HolgerJeromin]

Apparently MS honestly believes that trimming white space should only be done "on the current line" not every line in the file.

This is according to the spec: https://github.com/editorconfig/editorconfig/wiki/FAQ#my-files-are-not-automatically-reformatted-the-editorconfig-plugin-is-not-working

[ffes]

The wiki is not the official specs and probably outdated.

https://editorconfig-specification.readthedocs.io/#id9 clearly states:

trim_trailing_whitespace: Set to true to remove all whitespace characters preceding newline characters in the file and false to ensure it doesn’t.

[binki]

Is this related to how Visual Studio only changes CR/LF on lines that are edited instead of the whole file? I like how other editors handle this better, but it seems like they tried to map editorconfig things to native Visual Studio features and it just doesn’t have that feature.

[jgwinner]

Is this related to how Visual Studio only changes CR/LF on lines that are edited instead of the whole file?

Not sure that's true - when I open a file with mixed line endings, it asks, and if I say yes, it adds them to every line. This is before I've edited anything.

In any event, that's not what Visual Studio 2022 currently does. It only changes the line the cursor is on when you save the file. Just that line.

Basically it doesn't work at all, thus my interest in this plugin.

[binki]

@jgwinner

Not sure that's true - when I open a file with mixed line endings, it asks, and if I say yes, it adds them to every line. This is before I've edited anything.

In any event, that's not what Visual Studio 2022 currently does. It only changes the line the cursor is on when you save the file. Just that line.

Yes, this is a well-known issue. Visual Studio still has situations where it will load a file with one line ending convention, use a different one for lines which are edited or copied/pasted, save it with inconsistent line endings, and then, upon reopening later (perhaps after you already committed changes), ask you if you want to convert the file to consistent line endings. This seems to be an issue unique to Visual Studio which Microsoft won’t fix. See https://developercommunity.visualstudio.com/t/-/351278 and https://developercommunity.visualstudio.com/t/-/363894 (which are both marked solved even though people have followed up. Maybe it’s time to open a new one).

[bkaradzic]

What's actually issue with resurrecting this plugin?

1. No one from maintainers is interested updating plugin to work VS2019, VS2022?
2. Or there are some fundamental technical issues, and it's impossible or requires lot of work to be ported to VS2019, VS2022?

---

1. is fixable, by someone forking this project, and just updating what needs to be done to get VS2019, VS2022 support.
2. is too complicated, and should be explained here so people don't think you're not updating because there is jenky support for EditorConfig in VS, and you're expecting VS inept team to fix these issues.

Saying "Yes, this is a well-known issue." and providing VS community links is not helpful at all, since we wouldn't be here asking maintainers to update plugin if we had any hope that VS team can do it. This thread is proof that 5 years is not enough for inept VS team to fix issues with their buggy implementation of EditorConfig.

[ifarbod]

@bkaradzic I don't think complexity is an issue here, you'd just have to make it use the async API.