C# Code Style - New Prefer System.HashCode in GetHashCode option is not supported in .editorconfig

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

In VS 2019 16.5 a new C# code style option appeared in the Options window.

Prefer 'System.HashCode' in 'GetHashCode'

However, if you export the .editorconfig file, this option isn't present.
It is also not documented on any of the doc pages

https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference?view=vs-2019

I assume as all the other code style options are, this should also be.

---

Original Comments

Visual Studio Feedback System on 3/22/2020, 11:12 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

---

Original Solutions

(no solutions)

[allisonchou]

Notes from today's design meeting (4/13):

• While unfortunately no .editorconfig rule currently exists, a workaround for this issue would be to include the following line in the .editorconfig file: dotnet_diagnostic.IDE0070.severity = <severity>
• We recognize that the disconnect between Tools->Options and .editorconfig is an issue. Our goal is to eventually create a more uniform and seamless experience between the two. (See EditorConfig user interface  #39414 and Easy code cleanup with EditorConfig  #40163.)

[RehanSaeed]

I tried adding this to my .editorconfig file and it didn't seem to work. Restarted VS too.

dotnet_diagnostic.IDE0070.severity = <severity>

[Zastai]

Note that in VS2022 RTM, this option is shown when opening a .editorconfig (on those occasions where that editor doesn't crash).
But changing the setting or severity does not actually flag the .editorconfig as modified, nor is a value stored.

A disconnect between Options and an EditorConfig file is one thing. But showing a setting in the EditorConfig editing UX that does not actually reflect or modify the EditorConfig file is just bad.

[kevinmallinsonflynn]

I can confirm this is still an issue as of 2022-03-04:

Microsoft Visual Studio Enterprise 2022 (64-bit)
Version 17.0.5

Microsoft (R) Visual C# Compiler version 4.0.1-1.21568.1 (6ab6601)

[ValiantsinMaslionik]

I can confirm this is still an issue as of 2022-08-04:

Microsoft Visual Studio Professional 2022 (64-bit)
Version 17.2.5

[Youssef1313]

Note that in VS2022 RTM, this option is shown when opening a .editorconfig (on those occasions where that editor doesn't crash). But changing the setting or severity does not actually flag the .editorconfig as modified, nor is a value stored.

A disconnect between Options and an EditorConfig file is one thing. But showing a setting in the EditorConfig editing UX that does not actually reflect or modify the EditorConfig file is just bad.

I'm addressing this in #62939.

[Youssef1313]

Notes from today's design meeting (4/13):

• While unfortunately no .editorconfig rule currently exists, a workaround for this issue would be to include the following line in the .editorconfig file: dotnet_diagnostic.IDE0070.severity = <severity>
• We recognize that the disconnect between Tools->Options and .editorconfig is an issue. Our goal is to eventually create a more uniform and seamless experience between the two. (See EditorConfig user interface  #39414 and Easy code cleanup with EditorConfig  #40163.)

@allisonchou It's unclear to me what's the action needed for this issue? Do we want to support the code-style option in editorconfig?

[kkm000]

@Youssef1313: I'm no @allisonchou, but I think that the most consistent approach would be the adding of a new .editorconfig option. The option is present in VS2022 UI, both in the fancy .editorconfig editor, and under Options/Text Editor/C#/Code Style. Silently ignored in either, the .editorconfig generated with the button on the same Options page does not grep for 'hash'; the global setting under Options affects the IDE0070 behavior, however. Removing it from the former is still a half-way measure.

AFAIK, this is the only such option, w.r.t VS2022. Not sure about #58085, tho.