Changing the severity of a Sonar Qube category via .editorconfig does not work. It should work as it is documented here (-> 1) Configure the rules in a .editorconfig file that is not under source control)
and here
The same bug is reported here:
I want to lower the severity for all SonarQube analyzers to suggestion like this:
dotnet_analyzer_diagnostic.category-Minor Code Smell.severity = suggestion
We use treat warnings as errors and I do not want them to be reported as errors. Excluding every single SonarQube warning from treatment as errors is not an feasible option. Also setting the severity for every single one to suggestion isn’t.
This however works:
dotnet_diagnostic.S1066.severity = suggestion
As suspected in the former bug report maybe this has something to do with the spaces in the category name?
Would appreciate any help to globally lowering the severity level to that of the Roslynator analyzers.
Unfortunately, this is limitation from Roslyn on how they parse the category name.
Spaces are invalid in INI files and Roslyn does not provide any way to escape them.
thanks for taking your time for replying and further links.
However I do not feel it’s helpful that two projects point the finger at each other. It seems to be known from the Roslyn side since 3 1/2 years and it does not seem like a fix is around the corner. Yet it is a (user exerienced) problem on Sonarqube side. Instead of waiting for a Roslyn-side fix that probably will never come, finding a workaround Sonarqube-sided would be very nice.
Some ideas:
Why are the problems yielded at warnings at all? The (similar) Roslynator stuff is only yielded as message.
While I agree that it sucks that categories are “speaking descriptors to the user” on the one hand and “ids that may not contain spaces” at the same time, it would be an easy and practicable fix on Sonarqube side removing the spaces and using CamelCase or dashes in between. This might not be beautiful but it would get it fixed at least.
Couldn’t an extension setting be added that allows configuring the default warning level in the VS extension config UI? So we wouldn’t need to configure it .editorconfig side wise at all.
Message only show up in the IDE and not during the compilation. In my opinion, this would lead to the problems being overlooked or sometimes ignored as interpreted as not relevant or important.
As you said, having a fix on SonarQube side would be nice. However, this would all our customers as we use those categories not only on .NET but also other languages such as Java, C/C++, JavaScript (just to name a few). As far I know, this issue seems to exist on .NET.
I think you can imagine what impact it could have on all our products.
I am not sure how this would allow to fix the current issue, we still heavily rely on Roslyn providing us all the severities configuration.
To make things move on Roslyn side, I encourage you to add your voice to the Roslyn issue.
As of today, we don’t plan to implement a workaround for this particular issue.
