IDE name and flavor/env: Visual Studio Pro 2022, JetBrains Rider 2024.3.2+
The organization I work for uses the multirepo approach to source control and to my regret it will not change in the observable future. We have around 310 repositories at the moment, of which somewhere between 50-75% are using SonarCloud for static code analysis.
Our software developers are actively using Visual Studio 2022 and JetBrains Rider; VS being a formal standard, and Rider being a superior personal-preference permitted IDE.
Question: How to configure SonarLint/SonarCloud’s settings for the connected mode to be source-controlled and IDE-agnostic?
I thought that we could just keep .sonarlint/*.json in the root of the repository and have the IDE-specific plugins read the configuration from there. However, from my experience, only the Visual Studio’s plugin respects that config directory, while the Rider IDE ignores it altogether and shows the popup notification inviting to configure the Connected mode.
Hopefully, these threads are outdated, and this has changed by now. Otherwise, I agree with @ TheNybbler’s comment on the latter one that the direction away from a git-controlled config is a backwards step from the user perspective. Please consider what ESLint does for its configuration and mimic that behavior.
This way it would be:
IDE-agnostic (no maintenance burden) and
Zero-action for developer on repository checkout — we can’t afford configuring each time we checkout a new repo, as they are too many.
Hello @another-guy, and thanks for your valuable feedback.
However, from my experience, only the Visual Studio’s plugin respects that config directory, while the Rider IDE ignores it altogether and shows the popup notification inviting you to configure the Connected mode.
We aim for a similar experience in every flavor of SonarQube for IDE, leading to an IDE-agnostic solution. Could you elaborate on the discrepancy you see with Rider? Normally, you should receive a notification while opening the IDE, inviting you to use the Connected Mode configuration shared in the .sonarlint/*.json file, whether you are in Rider or Visual Studio. Isn’t that the case today?
Zero-action for developer on repository checkout—we can’t afford configuring each time we check out a new repo, as there are too many.
Currently, the user must confirm that he wants to use the shared Connected Mode configuration, which triggers a simple process where only generating/providing a token is required from the user. We aimed for a close to one-click experience, but we would be happy to hear any feedback or ideas from you on how the perfect setup would be.
The only way that semi-work and satisfies my requirements is the one that relies on git-controlled configuration residing in .sonarlint directory. According to this post, this way is being deprecated: SonarLint for Visual Studio v7.0 - Connected mode settings are moving to a new place. The new way of storing the bindings, moves them to %AppData%\Roaming\SonarLint for Visual Studio\Bindings, which does not work across IDEs
What I mean by “not working” is that if I set the binding using the Visual Studio and then switch to Rider IDE it does not detect that binding. I suspect, this happens either due to a bug or Rider seeking for the sonarlint config in a different location altogether (perhaps, .idea?)
In my opinion, the binding configuration should reside in .sonarlint the way it was done before. This decision has nothing to do with the way the access token is stored. Since access token is a secret, it indeed should be persisted in a different location, outside of the sonarlint settings. Look at how this problem is solved in Git. The configuration is defined hierarchically (~/.gitconfig being at the top and <repo>/.git at repo level and under), but it doesn’t contain the access tokens. The credentials are managed by a separate solution like Git Credential Manager.
I’d like to get assurances that the .sonarlint directory is not going away and will remain the first-class location for bindings. This is the only way my team can rely on for sharing via source control.
The only way that semi-work and satisfies my requirements is the one that relies on git-controlled configuration residing in .sonarlint directory. According to this post, this way is being deprecated: SonarLint for Visual Studio v7.0 - Connected mode settings are moving to a new place. The new way of storing the bindings, moves them to %AppData%\Roaming\SonarLint for Visual Studio\Bindings , which does not work across IDEs
SonarQube for Visual Studio (formerly SonarLint) stores additional information about the binding and the connected mode experience in the path %AppData%\Roaming\SonarLint for Visual Studio\Bindings. But if no binding is configured and a shared configuration is detected in the .sonarlint folder, it will trigger a simple process once the user confirmed that he wants to use the shared configuration. Please see the documentation for more info.
What I mean by “not working” is that if I set the binding using the Visual Studio and then switch to Rider IDE it does not detect that binding. I suspect, this happens either due to a bug or Rider seeking for the sonarlint config in a different location altogether (perhaps, .idea ?)
Is it possible that the .sonarlint folder does not exist for that particular solution? In SonarQube for Visual Studio, the binding configuration must be shared by clicking on the “Export Binding Configuration” button (see documentation).
I’d like to get assurances that the .sonarlint directory is not going away and will remain the first-class location for bindings. This is the only way my team can rely on for sharing via source control.
You can be assured that the .sonarlint directory is not going away and it remains the place where the shared binding configuration is stored and respected by every flavor of SonarQube for IDE.
.