sonar-dotnet
sonar-dotnet copied to clipboard
SonarSource
Update rule activation to be compatible with .editorconfig
Description
S3900 does not show up in Visual Studio
Repro steps
Install Visual Studio Install Sonar nuget Have a .editorconfig specifying "dotnet_diagnostic.S3900.severity = warning" at the root of your directory Copy and paste the code described as non-compliant in https://rules.sonarsource.com/csharp/RSPEC-3900 See that no warning is displayed in Visual Studio
Optional: Run analysis in SonarQube See that the warning is raised
Known workarounds
Use SonarQube to be aware of warnings
Related information
Visual Studio 2019 16.10.3 Sonar nuget 8.27.0.35380 SonarQube 9.0.1 Windows 10 20H2
Hi @lflender,
Rule S3900 is not part of our Sonar Way profile so it's not activated by default. You need to activate the rule in a ruleset file attached to your project.
Ruleset files were recently deprecated by MS and .editorconfig should be the replacement. Why VS doesn't activate the rule in this scenario and RuleSet does is a good question that you can ask the MS .NET team: https://github.com/dotnet/roslyn/issues
As described in the repro steps, I am using a .editorconfig file with the warning manually activated. Works for all warnings but this one.
We don't read .editorconfig nor ruleset ourselves. Visual Studio / Roslyn takes care about reading project configuration and activating rules.
@pavel-mikula-sonarsource It looks like this code is trying to handle the enabling/disabling outside of Roslyn:
https://github.com/SonarSource/sonar-dotnet/blob/5af5869f89f5aa4dede4903258b6cc18ef64783f/analyzers/src/SonarAnalyzer.CSharp/Rules/SymbolicExecution/SymbolicExecutionAnalyzerFactory.cs#L71-L80
Compilation.Options will work with .globalconfig files, but if you enable the rule in .editorconfig it will only be part of the options associated with individual syntax trees.
The following code relies on the above, which is preventing rules from registering any callbacks if they are enabled via .editorconfig:
https://github.com/SonarSource/sonar-dotnet/blob/5af5869f89f5aa4dede4903258b6cc18ef64783f/analyzers/src/SonarAnalyzer.CSharp/Rules/SymbolicExecution/SymbolicExecutionRunner.cs#L97-L100
Hi @sharwell, thanks for the insights! I'm reopening this and we'll try to rearrange the activation in the future.
Could you please give this more priority, again. We have a lot of issue with this, as rulesets are not really controllable with .editorconfig or .globalconfig.
The precedence rules for conflicting severity entries from a ruleset file and an EditorConfig or global AnalyzerConfig file is undefined.
Source: https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-files#severity-options
For the developers its always unpredictable what happens on the build-server.
Locally, no warning. We also using SonarQube Analyzer NuGet, which is perfectly controllable via .editorconfig. But things becomes strange, when the .sonarqube folder is present. There are rulesets in it, which now start interfering, with other settings.
As an alternative, an .editorconfig file can be used to disable the analysis for a specific rule on a file or directory. This can solve performance problems on large files.
Source: https://docs.sonarqube.org/latest/analysis/languages/csharp/#header-3
And as you also stating, rules are configurable via .editorconfig, I really think it's a serious bug.
Hi @cmenzi, this issue is specific to S3900 rule and very few others related to our symbolic execution. We'll try to fix that this year.
If you have a problem with the fact that the combination of editorconfig and ruleset is undefined by-design, you need to contact Microsoft. We can't change the Roslyn behavior.