We recently configured SonarQube to analyse our project builds (using on-premise Azure DevOps) and it’s great to see the results. In an ideal world our developers would get to see the SonarQube issues on their machine before check-in. We have a very large codebase, consisting of 15-20 solution files, with each solution containing tens of projects (c# and VB.net). We have a single SonarQube project covering our entire codebase.
I’ve downloaded and installed SonarLint on my machine, and configured a connection to or SonarQube server. I opened one solution and did a bind to our SonarQube project. It checked-out all the project files in the solution and added a ruleset file. Is this correct? Is there a way to create a global ruleset that we can use from all our projects?
If I right-click in solution explorer and choose “Analyse and Code Cleanup/Run code analysis” the results seem a bit hit and miss. Am I doing something wrong? Is there a web page that describes the best way to setup and integrate with a large codebase?
UPDATE: I’ve read through https://jira.sonarsource.com/browse/MMF-1267. I’m using connected mode, I don’t have nuget analysers installed. That issue refers to “A second stage will be stop generating a ruleset file per project, but instead just to set the ruleset property in the project file to point directly to the solution-level ruleset file”. Has this second stage been done? It seems that every time I open a solution I’m prompted by SonarLint “One or more rulesets are out of data or not linked to the SonarQube quality profile ruleset…”. If I click update then a ruleset is added for each project file, which I’m trying to avoid.
Hi @pete757. Apologies for the delay in responding.
The second stage of not adding rulesets to projects during binding has not been done.
However, SLVS is now smart enough to recognise if the generated ruleset is referenced by a project, and if so it won’t prompt to add a reference to it.
You could do the following to avoid adding a ruleset for each project:
bind the solution, which will create the generated ruleset and all of the project-level rulesets, then
revert all of the project-level changes and delete the project-level rulesets.
manually add references from each product project to the generated ruleset.
There are number of ways you could do this e.g. by directly adding a <CodeAnalysisRuleset> property to each project that points at the generated ruleset.
Alternatively, if you are using MSBuild 15 or later you could avoid changing the projects at all by adding a Directory.Build.props file that contains the <CodeAnalysisRuleset> property.
Analyse and Code Cleanup/Run code analysis
This functionality is all provided by Visual Studio itself. SonarLint and the SonarC#VB analysers don’t have any control over what happens. Unfortunately, “hit and miss” is a good description of the current experience.
As it says in the MS docs, the Run Code Analysis menu commands only work with legacy FxCop analyzers, rather than Roslyn analysers like those provided by SonarLint.
However, code cleanup is a new feature that was introduced in VS2019 so it must be working with Roslyn analyzers rather than the legacy FxCop analyzers. It’s currently quite limited, and this list of fixers seems to be hard-coded to those provided by the IDE currently.