SonarLint Connected Mode for SonarCloud setup for VS Code, VS and Rider

SonarQube for IDE
, , , ,
1

Information:

  • Operating system: Windows 10 Enterprise v10.0.19045
  • IDE name and flavor/env:
    – Visual Studio Professional 2022
    – JetBrains Rider
    – Visual Studio Code

And a thorough description of the problem / question:

Hi

I am trying to figure out how SonarLint Connected Mode works in the different IDE’s and I wonder what is important and what not. We have a team of developers that use different IDE’s (Visual Studio, Visual Studio Code and Rider) and I’m looking to find what is actually needed in order for the SonarLint extensions in the different IDE’s to work.

We use SonarCloud and work with .NET projects. A SonarCloud project is linked to a solution.

Personally, I am using Visual Studio. I see that SonarLint for Visual Studio needs/creates a “.sonarlint” folder in the Git repository with the following files:

  • {project}/{profile}/SonarLint.xml
  • .slconfig
  • .{project}{profile}.ruleset
  • sonar.settings.json

Next to these files, every project in the solution, needs to reference the “SonarLint.xml” in the “.sonarlint” folder. I found this here: SonarLint.xml is added to every VS project? Where can I read about it? - Stack Overflow

Now my collegue is using Rider. There we notice that Rider SonarLint Connected Mode does not create this “.sonarlint” folder in the Git repository, but that it creates it’s local files in “.idea” folder, which is ignored in our .gitignore file. The format of these files also seems to be different then the ones Visual Studio creates (no .slconfig, .ruleset)

And when I take a look at Visual Studio Code, there it seems to be also different (.sonarcloud.properties file).

So my question is, what is the point of checking in the Visual Studio files when other editors use their own way of setting this up? Should we just ignore those SonarLint files from the repository and let every developer setup SonarLint as they wish?

2

Hello @JenteVets and Welcome to the Community,

I’d like to give you a quick overview regarding the different flavors of SonarLint and the settings and their file and folder structures:

The different folder structures are based on the different IDEs using a different flavor of SonarLint. Meaning while all of it is “SonarLint”, the IDEs themselves differ and therefore we chose to create independent plug-ins (most of them sharing partly the same logic), also because plugins for Visual Studio can only be programmed via .NET (C#, …) languages while an Eclipse / IntelliJ plugin is created with a JVM language (Java, …).

As an example, JetBrains IDEs and Eclipse share most of the logic, but Eclipse stores every project setting by default (and by a convention of their platform) in a “.settings” folder whereas IntelliJ saves everything in a “.idea” folder.
Visual Studio Code always uses the “.vscode” folder for settings and we went with using the IDE-specific conventions first instead of every IDE plug-in having a dedicated ".sonarlint’ folder at the topmost folder (like in Visual Studio) which is interchangeable between the IDEs (for now, this may change at one point).

I can give you my personal perspective and opinion as I also worked on projects where developers were using Eclipse and other ones were using IntelliJ (similar to your colleagues using three IDEs) and how we managed the shared configuration “issue”.
As we had a “primary” IDE (namely Eclipse) it was chosen to save all the settings files inside Git so everyone had the same settings. When some people were moving to IntelliJ of course the question arose how to handle it then: Either remove the Eclipse settings or also save IntelliJ (the same as in Rider) settings alongside.

The issue with saving the configuration files / settings alongside everything else in Git is that different people have different IDE plug-in versions might cause issues because of breaking changes or force people to always use the same IDE version and the same plug-in version (like a company-wide rollout).
This does not take into account having different IDEs in the loop.

My personal opinion is that most people have a project checked out on their drive configure their IDE (and in this case SonarLint) once and then develop on it. Therefore configuring SonarLint and/or SonarQube / SonarCloud connection must be done only once and maybe when something changes again but not on a regular basis. This is the “developer is managing everything on its own”-approach.
The other approach would be the “everything is checked in”-approach (as mentioned above).

I personally like it more to choose my own tools but have to take into account that I might be the one to set it up and configure it. Of course, having a HOWTO written down is neat when I break everything and have to check out a repository and set up my IDE from scratch.

In the end, it is up to for you to choose the approach, maybe also adding more approaches (generating SonarLint files through self-built logic) might be possible but I don’t take this into account here.

But hopefully, it answered some of your questions, if you have more, feel free to reach out!

Best,
Tobias from SonarLint for Eclipse

5

Hi Tobias

Thanks for the extensive reply! Really gives good insight and provides context. We can work with this and will probably exclude those folder from Git and let every developer set up their own connection.

Again thanks for the fast and extensive reply.

Kind regards
Jente

1 Like
6

Hi @JenteVets,

on quick last answer with information for you: A new SonarLint for Visual Studio version was just released, changing the way settings are saved. I’ll leave you with the announcement thread HERE as it might be interesting for you, independent of your decision :slight_smile:

Best,
Tobias

8

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