Configuring inspection severities with EditorConfig

In our previous post, we looked at how we can maintain a consistent code style with the newly added formatting inspections in ReSharper and Rider. In this post, we will look at the different ways to configure inspection severities.

In this series:

Starting with ReSharper 2017.1 it was possible to define ReSharper formatting style settings directly inside the EditorConfig file. This allows us to keep our coding style settings in a central place, no matter what IDE other developers in our team are using.

With ReSharper 2018.1 EAP and Rider 2018.1 EAP, we improve our support for EditorConfig to read even more ReSharper settings from the EditorConfig file, including inspection severities and non-formatter code style settings. First, we need to enable this feature in Options | Code Inspection | Settings:

Enable reading severities from editorconfig and project settings

Note: Especially in large solutions, enabling this option can have noticeable performance impact. We consider it an experimental feature with planned performance optimizations in future releases.

ReSharper inspection severities inside the EditorConfig file are defined as resharper_[id]_highlighting where the id must be lower_case_with_underscore. Depending on our needs, we can assign any value of do_not_show, hint, suggestion, warning or error.

An appropriate UI for saving these values is planned for future releases. Our web help provides an index of all EditorConfig properties, which is convenient for searching. We can also grab the highlighting id from the relevant DotSettings file and then use it in our EditorConfig file:

For some folks, it might be worth mentioning, that after we’ve enabled this setting, we will also get support for reading severities from per-project DotSettings. Unfortunately, we still don’t provide any UI for modifying per-project DotSettings, but there is an older blog post, which describes a workaround of temporarily loading the DotSettings file as an options layer.

Stay tuned for the next part of this series, in which we will see how ReSharper and Rider integrate with Roslyn conventions.

Download ReSharper 2018.1 EAP now! Or give Rider 2018.1 EAP a try. We’d love to hear your feedback!

About Matthias Koch

Matthias is a passionate C# developer and likes to talk about clean code, testing and tooling in general. Much of his spare time in the last years was devoted to his very own open source projects, including NUKE. He is working at JetBrains as developer advocate for the .NET department. Follow him on Twitter.
This entry was posted in How-To's and tagged , , , , , , . Bookmark the permalink.

5 Responses to Configuring inspection severities with EditorConfig

  1. Chris says:


    With all these blog posts, it seems like that it would be important to go backward too and export resharper settings into .editorconfig to be used by non-resharper users.

    After a bit of research I found the following task:

    It looks however, to be targeting 2018.2.

    As most of your users will be using resharper already, the more important task would be going resharper -> editorconfig and not editorconfig -> resharper.

    So is it possible to push this task to 2018.1 as that would be the primary use-case for your user base.

  2. Pingback: What’s New in ReSharper C++ 2018.1 - ReSharper C++ BlogReSharper C++ Blog

Leave a Reply to Matthias Koch Cancel reply

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