Not all Code Smells showing up in Sonar Lint for VisualStudio

SonarLint Visual Studio
, ,
1

Please provide

  • Operating system: Windows 10
  • SonarLint plugin version: 6.5.0.48666
  • Is connected mode used: yes
    • Connected to SonarCloud or SonarQube (and which version): 9.5

In SonarQube I see for example csharpsquid:S109 but this does not appear in Visual Studio.
This is in a test project - I don’t know if that is relevant or not - I have <SonarQubeTestProject>false</SonarQubeTestProject> set
I do see other issues such as csharpsquid:S3994

This isn’t the only one that does not appear, just an example of same.

Is this a known issue?

4

Hi @tbutler. Apologies for the delay in replying.

Adding <SonarQubeTestProject>false<SonarQubeTestProject> should be enough to make SonarLint include the project in the set of bound projects, and analyse it using the rules configured in the Quality Profile.

A couple of questions:

  • does the test project have a reference to the generated CSharp .ruleset file?
  • what Action does the generated .ruleset file contain for rule S109?

If the test project doesn’t have a reference to the generated CSharp .ruleset file then as a workaround you could manually add one.

6

Hi @duncanp
I can confirm:

  • false is false
  • The ruleset is included in both the test and non test project
  • Both S109 and S3994 fire in a non-test project in the same solution, using the example non-compliant code from the rule descriptions
  • Only S3994 fires when I copy the same rule into the test project
  • Since I repored the issue originally I have updated Sonarlint to 6.7.0.52071 and the problem persist.

thanks

7

Hi @tbutler.

In short, yes, although it took some digging to confirm it.

SLVS-#1336 Issues reported in the IDE should match those on the server is an umbrella ticket that lists the known problems that causes differences in the analysis results.
In this case, SLVS-#1337 SLVS should support S4MSB properties is also relevant.

The longer explanation is that S109 will run only against “main” sources i.e. not test code. This isn’t apparent from rules.sonarsource.com (e.g. S109), but it is if you look at the rule definition in SonarCloud (here).

When running under the SonarScanner for .NET, the SonarQubeTestProject property is taken into account, so the project is classified as “Main” code and S109 is run.

When running in SonarLint, the SonarQubeTestProject property is not taken into account, the project is classified as a “test” project by the analyzers, and S109 is not run.

I hope this helps explain the results you are seeing.

9

Hi @duncanp

Thanks for confirming it is an issue - I can’t see in your link to the rule where it is apparent that the rule only runs against “main” sources? There is nothing in the rule text to suggest that.

I guess the real issue is that SonarLint simply does not respect the SonarQubeTestProject setting so yes your post does explain the results I am seeing.
The issue you mention has been open for > 2 years now - does that mean it is effectively dead on a backlog somewhere or is there any realistic chance of it being addressed any time soon?

Inconsistent behaviour between SonarLint and SonarQube itself is one of the big reasons why I cannot recommend SonarLint to our engineers - it adds little value if is not failing a build in Visual Studio for the same reasons the build would fail in CI where it is running the sonar scanner.

Thanks