NDepend Blog

Improve your .NET code quality with NDepend

The .editorconfig files for .NET developers

March 29, 2024 4 minutes read

editorconfig file for .NET developers

In software development, ensuring uniform coding styles across different editors and IDEs is challenging. .editorconfig files offer a universal solution to this problem, transcending language and platform boundaries, including .NET. These configuration files standardize coding practices, helping developers maintain consistent code regardless of their tools. This article delves into the role and usage of .editorconfig in .NET projects.

.editorconfig as a textual file format

The .editorconfig project (see the website https://editorconfig.org/ ) defines a textual file format designed to outline coding styles, along with a suite of text editor plugins that allow editors to interpret this format and comply with the specified styles. .editorconfig files are straightforward to read and integrate seamlessly with version control systems.

The .editorconfig file content shown below sets a default indentation style of 3 spaces for all files but specifically alters this to 2 spaces for .json files. Then it defines some C# style preferences:

Textual file format is convenient. Commit the .editorconfig file to your source control system to share it with your team. The coding styles defined in the file will be automatically enforced by compatible editors and IDEs used by the team members.

Organization and Priority of .editorconfig Files

.editorconfig files apply settings hierarchically, affecting files in their directory and all subdirectories. You can override these settings at any level by placing a new .editorconfig file in a subdirectory. In the example below, .editorconfig (B) overrides settings in .editorconfig (A).

By setting root=true in the .editorconfig file at a specific level, you can prevent the inheritance of settings from parent directories. This feature is particularly useful when you do not have control over the files in higher-level directories.

.editorconfig and .NET

Microsoft adopted .editorconfig for C# VB.NET and F# starting with Visual Studio 2017.

Visual Studio supports .editorconfig files natively but VSCode requires this EditorConfig for VS Code extension to handle it. Concerning JetBrains Rider, by default the IDE adheres to .editorconfig settings, which will supersede any preferences set within JetBrains Rider’s own settings. Should you wish for JetBrains Rider to disregard .editorconfig styles concerning code formatting and syntax, simply uncheck the relevant box located in the Editor > Code Style > General section of the JetBrains Rider settings.

In Visual Studio you can create a new .editorconfig file this way:

New Editor Config in VisualStudio

Visual Studio proposes a sweet User Interface to deal with C# and .NET editor config settings.

  • Settings are grouped into 4 categories, Whitespace, Code Style, Naming Style, and Analyzers.
  • Observe the convenient Search Settings textbox, designed to navigate through the multitude of settings, styles, and analyzers.
  • For each setting, you can see and change the value and also see the location from which it is inherited.

Editor Config in VisualStudio

Applying settings changed within .editorconfig

Be aware that modifying a setting such as Indentation Size and saving the .editorconfig file does not automatically adjust the formatting in any concerned source files. Instead, the source code editor will display squiggles, indicating that the tab settings from the .editorconfig are not in effect in the file being edited. To correct the tabs, you can execute Code Cleanup on the file. Additionally, there is a feature (found under Tools > Options) that allows you to automatically perform Code Cleanup whenever a source file is saved.

VisualStudio Code Cleanup

Notice you can run Code Cleanup globally from this solution menu. In our example, it would adjust Indentation Size within all source files.

VisualStudio Code Cleanup Global

.editorconfig and Roslyn Analyzers

The editor config’s Analyzers section refers to Roslyn Analyzers. Starting with Visual Studio 2019 version 16.5, rule set files have been superseded by .editorconfig files for the configuration of analyzers for managed code.

.editorconfig and Roslyn Analyzers

Looking at the textual view, configuring Roslyn Analyzers looks like this.

The severity ranges into:

  • none: (Disabled into the UI), the analyzers gets ignored.
  • silent: (Refactor Only into the UI). It means that Visual Studio will still present the code fix through a light bulb refactoring action, despite the user not being able to see the underlying hidden diagnostic.
  • suggestion: Violations are displayed in the Message tab of the Error List window, yet they do not appear in the output of command-line builds. In the editor the issue is underlined with a gray squiggle line.
  • warning: Violations are shown in the Warning tab of the Error List window and are included in the output of command-line builds, but they do not lead to build failures. In the editor the issue is underlined with a green squiggle line.
  • error: Violations are displayed in the Error tab of the Error List window and in the output of command-line builds, leading to build failures. In the editor the issue is underlined with a red squiggle line.

Btw, you might be interested in reporting newly introduced Roslyn Analyzers’ issues directly from your CI/CD pipeline with our tool NDepend as explained in the link:



.editorconfig files offer a simple yet powerful mechanism for enforcing consistent coding standards across .NET projects. By integrating these files into your development workflow, you can significantly improve code quality, enhance team collaboration, and streamline the development process. Remember, the goal of using .editorconfig is not to restrict developers but to create a more cohesive and efficient coding environment.


Leave a Reply

Your email address will not be published. Required fields are marked *