Hierarchical .editorconfig files not properly supported by Visual Studio editor

[vsfeedback]

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

---

Introduction

I’m using multiple .editorconfig files within my solution:

• One in the root directory, with generic settings for all projects in the solution
• Additional ones in the subdirectories, which inherit the settings from the root directory (using root = false) and add individual settings for each project.

The settings themselves appear to be applied as intended, the hierarchy is honored and, for example, the effective severity of each rule appears to be correct. However, the built-in Visual Studio editor for .editorconfig files does not properly support this setup for several reasons:

Issue #1: Listing of project-specific settings

When opening the root .editorconfig, the editor lists (in the Analyzers tab) the analyzers of all projects it can find in the solution. It even attempts to aggregate the rule severities configured in the project-specific .editorconfig files.

For example, in the repro provided below, analyzer rule NUnit2001 is available only in the test project and configured only in its .editorconfig, but not in the root .editorconfig. Still, the editor lists the following for the root .editorconfig:

This is confusing and error-prone, especially if several project-specific .editorconfig files configure different settings for the same analyzer. In my point of view, the editor should not list any analyzers at all if it cannot attribute the opened file to a project from which it can derive the active analyzers.

I could not evaluate if the same holds true for the configuration of formatting rules, code style rules and naming rules (because these settings must be present in the root .editorconfig, so I would never see the values aggregated from the project-specific settings), but the behavior would probably be the same. In general, I think the editor should only list whatever is explicitly configured in the opened .editorconfig and never pick up anything from the lower-level directories.

Issue #2: Incorrect location of settings

For settings inherited from the root .editorconfig, the editor incorrectly displays the local .editorconfig as the location.

For example, in the repro provided below, when opening src/.editorconfig, the editor displays this file as the location of the formatting settings, even though they have not been configured in this file but inherited instead:

The same holds true for the opposite direction: The editor displays the root .editorconfig as the location for settings which it has aggregated from the project-specific .editorconfig files. This can be seen in the screenshot shown for issue #1.

Issue #3: Settings listed multiple times

Whenever more than one .editorconfig is opened in the Visual Studio editor, the settings of all .editorconfig files are listed in each view. For example, with the repro provided below, opening all three .editorconfig results in the following view for each editor:

Close one of them and the remaining two will show each setting twice. Close another one and the last remaining will return to listing each setting once.

Even though each setting is attributed to the correct location and listed with the corresponding value, the duplicate listings cause a lot of confusion. Each editor view should list only what’s in the scope of the file it represents, regardless of which other file are open in parallel.

Issue #4: Inability to persist changes

When multiple .editorconfig files are present within the solution, it’s not possible to save changes made to settings in the Visual Studio editor. The editor tab does not display the asterisk symbol for unsaved changes and the save command does not result in the file being updated.

This holds true for inherited settings (in the repro provided below, this would be the operator placement, for example)…

… as well as for settings defined in the local .editorconfig (in the repro, this would be code quality rule CA1000, for example):

Once the editor is closed, the change is silently discarded.

Issue #5: Forced prepopulation due to ignored inherited default settings

Each .editorconfig file used with Visual Studio must contain a number of default settings. In case they aren’t already present in the file (which can be identified by the asterisk symbol for unsaved changes showing up in the editor tab immediately after opening the file in the editor), the editor will automatically add them upon saving. This behavior is normal.

However, at some point, the editor stops honoring default settings which have been inherited from the root .editorconfig and wants to save default settings. I still couldn’t figure out the exact pattern behind this behavior, but after loading the solution from the repro provided below, there’s always one of the project-specific .editorconfig files which has unsaved changes after opening it in the editor, while the other does not. After restarting Visual Studio, the roles sometimes randomly reverse.

Steps to reproduce

1. Create solution MyApp.sln:

   dotnet new sln --name MyApp
   

2. Create console application project src/MyApp.csproj:

   dotnet new console --name MyApp --output .\src
   

3. Create NUnit test project tests/MyApp.Tests.csproj:

   dotnet new nunit --name MyApp.Tests --output .\tests
   

4. Add both projects to the solution:

   dotnet sln MyApp.sln add .\src\MyApp.csproj .\tests\MyApp.Tests.csproj
   

5. Create an empty .editorconfig file in the root directory
6. Add the .editorconfig file to the solution as a solution item:
   Right-click solution in Solution Explorer > Add > Existing Item
7. Open the .editorconfig in Visual Studio and click save to populate the file with the mandatory default settings
8. Add the following line at the beginning of the file to prevent inheritance from higher-level directories:

   root = true
   

9. Add the following lines at the end of the file:

   [*.{cs,vb}]
   dotnet_diagnostic.CA1000.severity = warning
   dotnet_diagnostic.CA1001.severity = warning
   

10. Create another .editorconfig file in the src directory and add the following contents:

    root = false
    [*.{cs,vb}]  
    dotnet_diagnostic.CA1000.severity = error
    

11. Create another .editorconfig file in the tests directory and add the following contents:

    root = false
    [*.{cs,vb}]
    dotnet_diagnostic.NUnit2001.severity = warning
    

---

Original Comments

Feedback Bot on 8/6/2023, 09:22 PM:

(private comment, text removed)

---

Original Solutions

(no solutions)

[reinhardsaller]

Please refer to the original ticket linked at the top to view the images.