If I understand it correctly this change would mean, that starting with this version every developer now needs to bind the solution locally to a specific Sonar project, while before the binding was stored as part of the repository and developers only needed to configure credentials.
With the removal of the ruleset from the csproj, how can we have a consistent behavior when building using .NET CLI?
I have also problems in understanding all the consequences. Does it mean that every developer needs to install Sonarlint and connect to sonarqube server?
Also in our scenario we have sonarqube server with rules defined but our build pipelines do not yet integrate sonar analysis. So currently I was the only one in our team that used sonarqube in connected mode, thus having the rulesets integrated in our sources. This way all developers and build pipelines where not enforced yet to use Sonarlint/Sonar analysis tasks. It is unclear at the moment if our project will ever or when it will use the sonarqube analysis/sonarlint. What options do I have now? Install sonarlint < 7.0?
UPDATE:
I tried to uninstall v7.0 several times until Visual Studio did not show the extension anymore. After it was not visible in VS anymore I tried to install SonarLint.VSIX-6.16.0.69538-2022.vsix. But I get the following problem:
Install Error : Microsoft.VisualStudio.ExtensionManager.ReferenceConstraintException: The extension with identifier ‘SonarLint.0DE19254-1DCA-4479-8EAF-58E5D677FF4D’ could not be installed because one of its references’ constraints (Identifier: ‘SonarLint.AdditionalFiles.95521f6c-c3e6-460d-b0e6-aa64acd2fdb1’, MinVersion: 6.16.0.69538, MaxVersion: 6.16.0.69538) could not be satisfied since the reference is currently installed with version 7.0.0.74072.
Hello,
thanks to the feedback on SonarLint for Visual Studio v7.0, we’ve realized that those of you working with many solutions to connect to SonarQube have lost the ability for SonarLint to automatically bind based on configuration committed with the source code - we’ll be looking at ways to restore this ability in the near future.
how can we have a consistent behavior when building using .NET CLI?
TBH we do not consider SonarLint as a CLI linter so we’ve not considered this use case that far. Could you detail a bit more about what functionality are you missing when compiling in CLI? Do you want to see Sonar warnings as an output of the compilation? In this case, how are you going to process them and what do you do with the output? If you need a CLI tool to analyze your whole project, have you considered using SonarScanner for MSBuild instead?
thanks to the feedback on SonarLint for Visual Studio v7.0, we’ve realized that those of you working with many solutions to connect to SonarQube have lost the ability for SonarLint to automatically bind based on configuration committed with the source code
We also lost this ability with only a single project
TBH we do not consider SonarLint as a CLI linter so we’ve not considered this use case that far. Could you detail a bit more about what functionality are you missing when compiling in CLI? Do you want to see Sonar warnings as an output of the compilation? In this case, how are you going to process them and what do you do with the output? If you need a CLI tool to analyze your whole project, have you considered using SonarScanner for MSBuild instead?
See my detailed answer to this point here: v7 connected mode lost ability to centrally manage connected mode configuration · Issue #4514 · SonarSource/sonarlint-visualstudio · GitHub
@Marco_Comi
Thank you, that you value the feedback and take actions accordingly. We are also using many solutions with many developers and the ability to bind SonarLint to our SonarQube server automatically is important for us. Do you have any ETA for this feature?
Hello,
Among the different feedback we received about v7.0, some of you asked to reinstate the possibility of automatically setting up the connection to SonarQube, while other feedback was more directed to the possibility of sharing the quality profile (rules configuration) so that a connection to SonarQube is not needed at all.
We will work to provide an option to automatically set up the connection to SonarQube based on the configuration generated by one contributor and committed together with the project files. Please note that, at least in the first step, only the server URL and project key will be shared, not the quality profile.
I cannot give an exact ETA but we plan to work on this within the next couple of months.
Does this imply that you don’t plan to bring back the possibility to share the quality profile?
On the contrary, it’s something we’re considering - not only reinstating this possibility for Visual Studio (in an opt-in model) but for the whole SonarLint suite, possibly with a solution that can work for different IDEs. The are a few different reasons why developers want to share a quality profile directly with other collaborators rather than relying on connected mode, the most recurring one being network restrictions preventing them to connect to SonarQube.
You can this roadmap card, we don’t have an ETA but is likely we’ll be looking at this topic in the not-too-far future as well.