VS code. Connect mode project. just have all projects?

I’m using vscode with sonarlint. My organization is on sonarcloud and following @Julien_HENRY blog post from an old thread I’ve set up sonarlint to work with csharp. The issue we have is that we using a monorepo setup for our product, as such it contains many projects but we want them all to adhere to the same rules anyway. Below is the configuration I already have.

    "omnisharp.enableRoslynAnalyzers": true,
    "sonarlint.connectedMode.servers": [
        {
            "serverId": "sonarcloud",
            "serverUrl": "https://sonarcloud.io",
            "organizationKey": "[our organisation name]",
            "token": "[my token]"
        }
    ],
    "sonarlint.connectedMode.project": {
        "serverId": "sonarcloud",
        "projectKey": "*"
    }

In the project key I have put * which was my best guess at saying all projects. It works if I do use the project key of a project but again, I don’t want to mention a specific project just to Update all bindings.

Is there a way to solve this or simplify the problem?

Hi @shmink

First of all, using connected mode with a C# project will have no effect. SonarLint for VSCode is not supporting C#. The blog post you mention provides a way to use our C# analyzer directly with Omnisharp VScode. This is because our C# analyzer is in fact a Roslyn extension.

Now in case you still want to configure connected mode (for other languages), you have to bind to a specific SonarCloud project, because each project may have a different configuration (rules, exclusions, …).
With latest SonarLint VSCode release, we are supporting configuration per workspace folders. So you will have to open in your VSCode workspace one folder per SonarCloud project and then configure a binding in each folder settings. I can give more details if this is not clear.
If you splitted your mono repo in multiple SonarCloud projects, I think it should make sense to split it in multiple root folders in VSCode.

Not too try and detract from the topic too much but when, if ever will vscode SonarLint be able to support C# more seamlessly?

Also is there any plan on a similar extension for Rider?

We are considering it, but this is not totally on our hands. We would need to collaborate/hook into the omnisharp-vscode language server, and this is probably not a simple task.

Again, since our C# analyzer is a Roslyn extension, we are not totally free to run it as we like. I don’t know how Rider is working internally. Do they run on top of Rolsyn, or did Jetbrains developed its own frontend?

I couldn’t find a definitive answer about Rider but the following https://blog.jetbrains.com/dotnet/2018/03/22/roslyn-analyzer-support-rider-2018-1-eap/ has more information. Sorry for the digrestion.

Back to the original problem. You mention

using connected mode with a C# project will have no effect.

So even when I update all the bindings it’s not fetching any of the C# rules?

The blog post you mention provides a way to use our C# analyzer directly with Omnisharp VScode. This is because our C# analyzer is in fact a Roslyn extension.

Does it not matter that in OmniSharp options the support for roslyn analyzers has been enabled?

With latest SonarLint VSCode release, we are supporting configuration per workspace folders. So you will have to open in your VSCode workspace one folder per SonarCloud project and then configure a binding in each folder settings. I can give more details if this is not clear.

More information would be nice. Any particular docs or guide that has been created would be nice.

It is, because we are currently fetching all rules, but it won’t be passed to omnisharp, that has its own way to configure active rules (using ruleset.xml AFAIR).

Yes, last time I tried it was a pre-requisite.

First read https://code.visualstudio.com/docs/editor/multi-root-workspaces, then simply edit each workspace folder settings (right click on the folder -> Open Folder Settings) and set the sonarlint.connectedMode.project property to set the correct project key. The folder settings file can be stored in your SCM to share between developers.
Then they should only define sonarlint.connectedMode.servers once in their user settings, using the same serverId.

1 Like

It is, because we are currently fetching all rules, but it won’t be passed to omnisharp, that has its own way to configure active rules (using ruleset.xml AFAIR).

Would there not be a way then to replace that files content with the active sonar rules? I can generate an xml file of the rules from sonar.

EDIT: Apparently you can also use .ruleset files. Maybe when pulling the bindings it could create this file?

Yep, that is something I have in mind. In fact this is more or less what we are already doing in SonarLint for Visual Studio. But this is not that simple, especially if omnisharp can only accept a single ruleset file, because the user can already have configured some rules (for other Roslyn analyzers he may be using). So we would have to locate/amend the ruleset, and not blindly overwrite it.

In my use case it’s fine. Working in a company where everyone is adhering to the same rules it should be fine. As far as I can work out so far I could conceivably create a script in the root directory of the mono repo we are using. It pulls a specific ruleset (we’re using sonar way one :slight_smile: ) such created such as sonar.ruleset ?

And then as per this guide I just point at that sonar.ruleset file?

And I’m assuming it requires omnisharp.enableRoslynAnalyzers set to true.

Follow up: the below test.ruleset file has been added and pointed at.

<RuleSet Name="Test Rules" ToolsVersion="10.0">
  <Rules AnalyzerId="Microsoft.CodeAnalysis.CSharp.Features" RuleNamespace="Microsoft.CodeAnalysis.CSharp.Features">
    <Rule Id="IDE0060" Action="None" />
  </Rules>
  <Rules AnalyzerId="SonarAnalyzer.CSharp" RuleNamespace="SonarAnalyzer.CSharp">
    <Rule Id="S1128" Action="None" />
  </Rules>
</RuleSet>

the ID0060 is an omnisharp rule which is being applied and working as expected.
the S1128 is a sonar rule which seems to be ignored.
The sonar csharp nuget package installed. It seems to me that omnisharp is taking precedence when we don’t want it to.

But with just all sonar rules as intended we end up with both sonar warnings and omnisharp warnings.

bump.

This is not clear to me what you are expecting from us. If you think there is an issue in the way Omnisharp handle ruleset, it should be reported directly to them.

Regarding SonarLint support of C# in VSCode, as mentioned, this is in our radar, but not scheduled yet. Thanks for the ideas and experiment you made, it will certainly be helpful when we will start the work.