I am having a problem where issues reported in SonarQube are not shown in SonarLint connected mode, which makes them hard to fix since they only show up very late in the process. It is also confusing to developers.
To give an example, SonarQube finds two instances of rule “S2583: Conditionally executed blocks should be reachable” that do not show up in SonarLint. There are other rules that show the same behaviour. I have read the FAQ and the exceptions listed there do not apply to my project.
Here’s the setup, please let me know if I’ve missed something:
Visual Studio 2019
C#/.NET Standard as well as Core
SonarQube Version 7.9.2 (build 30863)
SonarLint Version 4.20.0.16339
All Projects in the solution also contain a reference to the NuGet Package SonarAnalyzer.CSharp ( Version 8.6.0.16497)
The ruleset file is applied via a Directory.Build.props file like this:
<PropertyGroup>
<CodeAnalysisRuleSet>{Path to ruleset file}</CodeAnalysisRuleSet>
</PropertyGroup>
Can you get S2583 issues to appear in VS in a new project, using the example non-compliant code from the rule description?
FYI I can see the issues in the IDE using the same versions you are using. I’ve tried various combinations: SonarLint only, NuGet package only, both SonarLint and NuGet package, and see the issues for all of them.
There a couple of possibilities why the results would be different in Connected Mode:
if the issues where marked as False positiveor Won't fix in SonarQube then they shouldn’t appear in the IDE, or
the rules are disabled in the Quality Profile for the SonarQube project (but in that case the issues wouldn’t be reported in SonarQube either).
You said you’re using Connected Mode but the ruleset property is specified in a Directory.Build.props file, which means someone must have manually edited the project settings after binding to SonarQube.
It would be worth double-checking that the correct ruleset is being passed to the compiler (i.e. that there isn’t another CodeAnalysisRuleSetproperty being set elsewhere). The easiest way to do to this would be to look at the parameters passed to the C# compiler (csc.exe) in the MSBuild output.
Yes, I can get issues from S2583 to appear in a new project containing the example code.
The issues are not marked as False positive or Won't Fix. I’ve looked at SonarLints output and it does find suppressions (4 of them) and the suppressed issues do not show up either. As you have already said, rule S2583 is not disabled.
You are right, I did edit the project settings after binding to sonarqube. The parameter /ruleset is only applied once, with the value <path-to-solution-dir>\.sonarlint\<filename>.ruleset, which is correct.
if you add the non-compliant code for S2583 in a new class in your connected project, are the issues reported in the IDE?
are any of the four suppressed issues for S2583 instances that appear on other lines in the file? It may be that the suppressions are being matched against the wrong issues.
are the issues correctly reported in the IDE if you temporarily unbind the solution? The easiest way to do this is to delete the solution-level .sonarlint folder and restart VS.
As an aside, you don’t need to have the SonarC#/VB NuGet packages installed if you have SonarLint installed, although it shouldn’t cause issues if you do. Historically, SLVS used to install the NuGet packages in Connected Mode but now it doesn’t. This section of the wiki describes how to tell whether you are using “legacy” connected mode or the “new” connected mode.
Yes, adding the concompliant code to a new class in the same project gets reported as S2583. This is also true if add the same noncompliant code to the file/class where the issues detected on the server are not reported (Let’s call it User.cs).
The four suppressed issues are not in User.cs. All four suppression are also for rule S2583, though (false positive). I also think the two instances of S2583 that show up in SonarQube but not in SonarLint might be false positives. There are no other issues reported in JetUser.cs, although one issue (S4035) is suppressed in source code via an attribute on the class, rather than in SonarQube.
If I unbind the solution, the issues are still not reported.
Thanks for the link. We are definitely running in the “new” mode.
So if I understand correctly, the four suppressions are for S2583 but relate to a different file?
Also, which version of the SonarC# plugin do have installed on your SonarQube server? I see from the SonarC# release notes that a lot of FPs have been fixed recently for a number of rules including S2583.
Yes, that is correct.
The IT department tells me that we are running version 7.15 of SonarC# plugin. I’ll try to get them to update it. I’ll let you know if that solves the problem or not.
Great. An alternative would be to downgrade the version of the NuGet package used by the projects to match the version on the server.
However, if you look at the release notes for SonarC# you’ll see that there have been a lot of improvements, new rules and fixes added to the analyzer in the nine months since the v7.15 was released, so the results you are seeing in the IDE will be better with the newer version.
So, SonarQube has been updated to version 8.2 with the SonarC# plugin at version 8.6. This solves the issue with S2583. Thank you again for your help with that!
However, some new issues have presented themselves. They seem to fall into two separate categories:
Rule Parameters aren’t being applied in SonarLint
On the SonarQube server, there are several issues caused by parametrized rules. As an example, we limit the maximum length of a file to 350 lines, as opposed to the default 1000 lines (rule S104). If I look at the .ruleset file, it only contains <Rule Id="S104" Action="Warning" /> but nothing that seems like a parameter. Should those be defined somewhere else?
“Reviewed as safe” is not taken into account in pipeline
We are also runnin an analysis in Azure Pipelines. There, several errors of rule S4834 (“Make sure that permissions are controlled safely here”) are reported. These exists on the SonarQube server as well, but are all marked as “safe”. They are not reported in SonarLint (although I believe this analysis is not part of SonarLint, so no suprise there, correct?).
Side note: In the pipeline, each issue is reported twice.
SLVS doesn’t currently apply rule parameters set on the server - see SLVS-176. The good news is that this ticket is in the current sprint, and we hope to include this feature in the next release of SLVS which should be released next week.
I’m not sure what the expected behaviour is. Could you open a separate thread about that please? That will make it easier to route to the correct person.
Are you targeting multiple frameworks in your projects? If you are, MSBuild will invoke the compiler once per framework, and an analysis will be performed each time. That’s the expected MSBuild/C# behaviour. However, the issues should only be reported once in SonarQube/SonarCloud.
FYI just an update on the release date for the next version of SLVS: we’ve finished implementing SLVS-176 (use the rule parameters set on the server), so it will be in the next release.
However, while testing we discovered a bug in the underlying SonarC#/VB analysers which means the settings are not applied correctly (SLVS#1421). This will be fixed in the next release of the SonarC#/VB analysers, which is planned for the end of next week/start of the week after. We aim to release the next version of SLVS as soon as we can after that i.e. around 8th June 2020.
