SonarLint not reporting issues in Connected mode in Rider

  • Operating system: Windows 10 Pro
  • SonarLint plugin version: 9.0.0.75308
  • Rider version: 2023.2.1
  • Programming language you’re coding in: C#
  • Is connected mode used:
    • Connected to SonarCloud or SonarQube (and which version): Community Edition - SonarQube 9.9 (build 65466)

I installed the SonarLint plugin in Rider and it worked i.e. it reported the expected issues.

I then connected it to our SonarQube and it stopped reporting issues. In the logs it still reports that it is analyzing files, however, it always returns 0 issues. After turning on verbose logs I noticed that I get:

No VCS repository found for module Module: 'rider.module'

Which is mentioned in Syncing of issue status in release branch to SonarLint - #5 by Julien_HENRY, however, the person in that thread was not getting that message.

The logs also contain the following sequence:
Binding suggestion computation queued for config scopes 'C:/[path to my project]/.idea/.idea.platform/.idea/misc.xml'...
Configuration scope 'C:/[path to my project]/.idea/.idea.platform/.idea/misc.xml' is already bound.
Stream has been cancelled
Restoring previous server issue database from C:\[path to app data local]\JetBrains\Rider2023.2\sonarlint\storage\[what looks like a hash]\projects\[what looks like a hash]\issues\backup.tar.gz
java.io.InterruptedIOException
Followed by the stack trace.

When I look for the misc.xml file it isn’t there, but there are other xml files present. The backup.tar.gz file is present.

Please forgive any errors from the logs as the issue is happening on a PC which is not connected to the internet so I’ve had to re-type the logs.

Hi @brendon1982

No VCS repository found for module Module: ‘rider.module’

This likely means your solution is not under source control, but that should not prevent SonarLint from reporting issues. This may only be a concern if you want to suppress issues.

There should not be a lot of difference in connected mode regarding the analysis. The only thing I can think of would be a problem synchronizing the quality profile from SonarQube.

Could you inspect the analysis logs in the SonarLint log panel, and look for something like:

Omnisharp: [DEBUG] ************ Request ************
{
  "Type": "request",
  "Seq": 1,
  "Command": "/sonarlint/config",
  "Arguments": {
    "activeRules": [
      {
        "ruleId": "S1854"
      },
      {
        "ruleId": "S4200"
      },
   [...]

You should be able to find in the list all the rule keys enabled in your quality profile on SonarQube. Please double check that you can see the rule keys you are expecting issues from. If not, then maybe those rules are not activated on SonarQube?

Hi Julien,

Thanks so much for your reply. After looking closely at the analysis logs I found the problem. The Omnisharp load was timing out. I must apologise as I had only turned on verbose logging and neglected to turn on the analysis logs, so I missed this when initially trying to debug the issue.

The error in the analysis logs directed me to Rider · SonarSource/sonarlint-intellij Wiki · GitHub where it suggested setting the analysis property sonar.cs.internal.loadProjectsOnDemand to true for large solutions to avoid the Omnisharp timeout. After doing this the message you suggested looking started appearing in the analysis logs and analysis started finding the expected issues.

Thanks again for your reply, it was the nudge I needed to come unstuck. I hope this post might help others in my situation.

1 Like

Happy to hear you found the solution, and thanks for the feedback. I wonder if at some point we should default to loadProjectsOnDemand to true…

That would’ve been useful for me, however, I’m guessing that there are tradeoffs that don’t make it an obvious choice.

The thing that caused most of my confusion was that the CSharp Sensor failure was essentially silent. By that I mean nothing in the UI indicated that there was a problem. To be fair once I turned on verbose and analysis logging the failure was shown in red in the logs, however, this was the only indication that a sensor had failed.

Thanks again for the help.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.