SonarLint and Sonarqube show different issues


we got a problem, that SonarLint and Sonarqube show different issues.

  • Operating system: Windows 10 Enterprise - 19044
  • IDE: JetBrains Rider 2022.2
  • SonarLint plugin version:
  • Is connected mode used: Yes
    • Sonarqube Enterprise Edition Version 9.6 (build 59041)

We successfully bound the project and also set our own Quality Profile (e.g. disabled “URIs should not be hardcoded”) and also tried with the “Sonar way DEFAULT BUILT-IN”. After the “Update” SonarLint removed the issue, so we are pretty sure the connection/bounding is working and the rules from the Sonarqube server are used.


SonarLint (Rider)


So in the IDE there are 10 Critical and 1 Major issues, while Sonarqube shows 11 Critical, 1 Major and 15 Minor issues.

We have this difference in issue count in many files and also with different rules (not only “Minor” issues are missing)

So how do we synchronize both SonarLint and Sonarqube?

Thank you :slight_smile:

Hello @helloingob,

Thanks for raising this question. Could you please share with us some of the issues you are able to see on SonarQube and not in SonarLint ?

You might also want to read this section of the FAQ, that explains some reasons you can face this situation.


here are the Sonarqube issues. Red marked are the issues, that are only in SonarQube.

and here is the verbose SonarLint log

Trigger: ACTION
[Action] 1 file(s) submitted
Configuring analysis with org.sonarlint.intellij.rider.RiderAnalysisConfigurator
Using connection 'SonarQube' for project 'XXXTool'
Analysing 'ConfirmationDataSheet.cs'...
Starting analysis with configuration:
  projectKey: XXXTool
  baseDir: C:\XXXTool
  extraProperties: {sonar.cs.internal.solutionPath=C:\XXXTool\XXX.sln, sonar.cs.internal.dotnetCliExeLocation=C:\Program Files\dotnet\dotnet.exe, sonar.cs.internal.msBuildPath=C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin}
  moduleKey: Module: 'rider.module'
  inputFiles: [
    file:///C:/XXX/git/XXXTool/XXX/ConfirmationDataSheet.cs (UTF-8)

Done in 1968ms

Processed 11 issues
Found 11 issues
Fetching server issues in 1 file (waiting for results)
downloadAllServerIssuesForFile projectKey=XXXTool, filepath=Configurator/XXX/ConfirmationDataSheet.cs
GET 200 https://XXX/api/system/status | response time=31ms
Downloaded server infos in 31ms

Thank you :slight_smile:

Thanks for those extra details, indeed those rules are supposed to be raised in SonarLint.

Now another round of questions:

  1. Could you make sure you activate both analysis logs and verbose ouptut options, re-open the solution, let SL analyze the file and share all the logs with us. Feel free to redact sensitive information
  2. Could you try the non-compliant sample code in this rule and check if it raises an issue ?
  3. If we focus on this rule, could you try to send us a minimal reproducer example from your project ?



here are both logs for the “ConfirmationDataSheet” file and the non-compliant sample code.

ConfirmationDataSheet.SL.log (136.8 KB)
NonCompliantCodeSample.SL.log (17.0 KB)

using System.Collections.Generic;

namespace XXX
    public class Element
        public string MyValue { get; set; }
    public class SolarLintConfig
        public void Config()
            var collection = new List<Element>();
            var collection2 = new List<Element>();
            var result = new List<string>();
            foreach (var element in collection)  // Noncompliant
                if (condition(element))

            foreach (var element in collection2) // Noncompliant
                var someValue = element.MyValue;
                if (someValue != null)

        public bool condition(Element element)
            return element != null;

I pushed the “NonCompliantCodeSample” and Sonarqube evaluated it. While there is no smell in Solarlint, Sonarqube detects it.

Hello Ingo,

Thanks for those samples.

The only explanation we have so far is that your project is considered a test project. The rules you mentioned are only run on main sources and not on test sources.

In SonarLint we determine if your project is a test project by checking your project references. If a known test assembly is referenced, the project is considered a test project. This is different when running with the Scanner. Could you check if it’s the case on your side ? Do you depend on test assemblies ?

For reference this is a recent related post on Visual Studio.

Hey Damien,

yes, we added <SonarQubeTestProject>false</SonarQubeTestProject> to our csproj file, since we have to import a nuget package with a NUnit reference in it. I thought SonarLint will pick it up aswell and handle it the same as Sonarqube.

Is there no other way to tell SonarLint which project is a test and which not?

Unfortunately, not at the moment. I will discuss this with the relevant teams and will post any update here