In VS2022 can you setup a solution wide editorconfig, and and project specific editorconfig that override?

Question

In Visual studio 2022, can you setup a solution wide .editorconfig file and and then project specific .editorconfig files that override or add to the solution wide one?

In my case, I am looking to have different settings for unit tests projects, and/or disable legacy method warnings on legacy projects.

Does Visual Studio 2022 support this?

---

Edit: As an added fyi, I am familiar with the MS documentation on .editorconfig folder hierarchy.

The method in the documentation did not work on my actual project or a purposely created demo project. It was tested on VS2022 17.4.3 and Preview 17.5. With experience, you will learn documentation and features do not always align.;)

Lindeman

Answer 1

Yes, the setup of .editorconfig files is hierarchical, where settings in child .editorconfig files add to or override those in parent .editorconfig files.

It is even possible to stop the inheritance starting from a certain level in a child folder by including root = true in that child .editorconfig file.

From the documentation

When you add an .editorconfig file to a folder in your file hierarchy, its settings apply to all applicable files at that level and below.

To override some or all of the EditorConfig settings, add an .editorconfig file at the level of the file hierarchy you want those overridden settings to apply. The new EditorConfig file settings apply to files at the same level and any subdirectories.

If you want to override some, but not all of the settings, specify just those settings in the .editorconfig file. Only those properties that you explicitly list in the lower-level file are overridden. Other settings from higher-level .editorconfig files continue to apply.

Such a folder and files hierarchy might look like below.

\ YourSolution
  - YourSolution.sln
  - .editorconfig
    ...      
  \ Src      
    \ Project1
      ...    
    \ Project2    
      ...
    \ Project3
      - .editorconfig    
      ...            
  \ Tests      
    - .editorconfig        
    \ Tests1
      ...          
    \ Tests2
      - .editorconfig

The root .editorconfig file can also be in a common parent folder for all your Visual Studio solutions.

\ YourSolutions
  - .editorconfig
  \ YourSolution1
    - YourSolution1.sln  
    ...
  \ YourSolution2
    - YourSolution2.sln
    ...
    

---

Example files.

Root .editorconfig file

[*.cs]
dotnet_sort_system_directives_first = true
dotnet_style_require_accessibility_modifiers = 
for_non_interface_members:error

Child folder .editorconfig file

[*.cs]
dotnet_sort_system_directives_first = false
dotnet_style_require_accessibility_modifiers = 
for_non_interface_members:silent

---

In VS2022 17.4.3+, when dealing with multiple .editorconfigs you may need to use a standard text editor instead of the default .editorconfig gui tool.

Implied

Were you able to accomplish this yourself, or are just extrapolating this from documentation that may be incorrect? I tried this in my project (and an example project), and it did not work. The documentation also does not refer to solutions vs. projects, but the rather vague folder. – Lindeman

Just as an aside, in the VS2022 specific documentation, it refers users to a "EditorConfig Language Service extension"... except that extension doesn't work for VS2022. – Lindeman

@Lindeman I've added (an extract of) my .editconfig files as an example. You might give those a try. Visual Studio 2022 doesn't require any additional extensions. The documentation mentions folders just because it isn't solution nor project bound. – Implied

@Lindeman Can you extend your question with what is not working? And share an extract of your .editorconfig file? – Implied

So I used a standard text editor instead of the VS2022 17.4.3 default GUI editor, and it is now working as described here. It looks like the editor was the issue as it did not save the update. The documentation on the editor is out of date in MSDN which is also added to the confusion. – Lindeman

Was any of you guys able to use the out of solution variant? – Lathrop

@PaulMichalik If by "out of solution" you mean having the .editorconfig file in a folder upwards to the one holding the solution file, then yes, that works out fine. – Implied

@Implied Hm. I must be doing something wrong. No matter which combination I try, the analyzer always ends up doing something unexpected. I am trying to set up a combination of .editorconfig in a project directory and a shared .globalconfig with analyzer priorities... It is really hard to tell, which of the settings actually apply in a specific situation. – Lathrop

@PaulMichalik I don´t have experience in mixing .editorconfig with .globalconfig files. Sounds like a candidate for a new question. – Implied

@Implied Okay, I see. I'll give it another try before resorting to third party tools. Will report on success. – Lathrop

Answer 2

The answer by pfx is an excellent overview using .editorconfig files - as described, they are hierarchical based on the directory, so precedence is always implied by how close the property is defined to the file (there can't be two .editorconfig files with equal precedence).

As a supplemental answer because you tagged C#, I'll also mention .globalconfig files. Where .editorconfig files apply to the contents of a directory, .globalconfig files are for applying analyzer rules based on project (or as part of a NuGet package). For example, if you have files linked into a project from outside the project folder, .editorconfig settings for that project will not be applied to those files, but .globalconfig settings will.

Globalconfig files can be inherited implicitly or explicitly included on a per-project basis (if named something other than ".globalconfig"). See https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-files#naming. This can help if your project structure looks something like this:

\ YourSolution
  - YourSolution.sln
  - .editorconfig
  - Directory.Build.props
    ...      
  \ Src      
    \ Feature1
      \src
        - Feature1.csproj
        ...
      \test
        - Feature1.Test.csproj
        ...
    \ Feature2
      \src
        - Feature2.csproj
        ...
      \test
        - Feature2.Test.csproj
        ...

In this case, you can define something in your Directory.Build.props file to apply only to test projects, such as

<PropertyGroup Condition="$(MSBuildProjectName.EndsWith('.Test'))">
  <GlobalAnalyzerConfigFiles Include="AnalyzerSettingsForTestProjects.globalconfig" />
</PropertyGroup>

Globalconfig files can conflict with each other or with .editorconfig files that apply to the same files. Globalconfig files can specify a global_level property to specify their relative precedence. .editorconfig will win over .globalconfig. The rules for conflict resolution are laid out here: https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-files#precedence

Potaufeu