Configure the mapping between SC severities and VS severities

SonarLint Product Manager for a Day
1

Hello,
I use SonarLint for VisualStudio2022 7.2.0.76209 on Windows.
My focus is on C# language and I am using connected mode to SonarCloud.

I read an old post where people where looking for a way to configure VS severity for rules defined in SonarCloud (Failing a build in the IDE for new code violations - #2 by duncanp).
I see that now file sonarlint_csharp.globalconfig is downloaded together with Sonar rules.
Yet, I fail to find a way to configure the severity to be applied in sonarlint_csharp.globalconfig.
Is this now allowed?

Thanks

2

Hey there.

This file will still not have anything to do with the mapping of SonarCloud issue severities to Visual Studio severities.

This section of the documentation describes how you can configure Treat warnings as errors to cause your IDE build to fail on any issues whatsoever. Is that what you’re trying to accomplish, or something else?

3

Hello Colin,
thanks for your reply, the link is surely useful.

Treat warnings as errors would impact all warnings, not just ones from SC, and obviously this is quite uncomfortable. The target is not that, it is to be able to make builds fail locally just when specific SC rules are not respected, avoiding a waste of time and resources.

I see that changing values on sonarlint_csharp.globalconfig, severity is correctly applied to VS, but it gets overridden updating the bind (it is actually the behavior that anybody would expect).
The best solution would be to configure the mapping between SC severities and VS severities by the SC platform.

The only not disruptive workaround that comes to my mind is to not enable Treat warnings as errors but to create a set of .editorconfig files for each solution.
Except for the initial cost to create and spread the files, than files should also be maintained.
Not exciting at all but nothing else comes to my mind…

4

Ah, I understand, you meant per-rule and not overall:

Yes – your suggestion should work (creating a set of .editorconfig files for each solution), and is what came to mind our developers when I spoke internally.

I’ll also move your post to the Product Manager for a Day category – this isn’t the first time we’ve received requests around this.

1 Like
5

Cool, hope to see something new in a future release.

I would add another point too.
Usually, VS solutions contain application code projects and test projects, but people want to apply a rigid validation just to application code.
This can be achieved by adding true to each test project for what concerns SonarCloud.
For SonarLint, I guess this is a little more tricky since rules are bound to the whole solution (afaik).
The solution I adopted is again to create a specific set of .editorconfig.
The solution works but it is nothing more than a workaround, maintaining those files for a large number of projects is going to be hard.

This scenario is more complicated than the previous one, and I actually cannot see any simple way to solve it. Yet, if you will work on this part, it could be a good point to analyze.