Demark a Visual Studio solution to a SonarQube project provisions and configures Roslyn analyzers

March 17th, 2016

A few weeks agone, we announced the SonarQube scanner for MSBuild ii.0 supports 3rd party Roslyn analyzers. This has been working for the continuous integration build. In this blog mail service we are announcing that we have extended this experience to the IDE. Yous tin can now bind a Visual Studio solution to a SonarQube project and see Roslyn analyzers automatically provisioned as NuGet packages, and rulesets configured, using the SonarQube Quality Profile for the project.

Allow's see what problem we are solving here, and how to use this new characteristic.

Analysis bug reported by build can be different from the ones in Visual Studio

Not-Dev build results can be unlike from warnings in the IDE

In previous posts nosotros have explained how you could setup a SonarQube analysis part of the non-dev builds (i.e. Continuous Integration builds or automated builds). We got the feedback that this is great, because you tin measure your technical debt and its evolution. Only we also heard that this can be very frustrating for developers, every bit sometimes, they go notified during the build that they introduced new bug, whereas they would really like to exist notified right when they develop in the IDE (in Visual Studio). This situation happens considering the definition of the quality in SonarQube is different from the configuration of the static assay rules which run when building or editing in Visual Studio. Let'due south understand this meliorate.

This is frustrating!

Let's imagine that I'm a programmer in a team who has enabled the SonarQube assay build in the continuous integration. In SonarQube, nosotros have installed the C# plug-in (version 5.0 or more than recent). Nosotros have used the SonarQube Roslyn SDK to build a SonarQube plugin that wraps the Wintellect Roslyn Analyzers. Then we have ready a Quality profile which enables rules from the C# plug-in (really "Sonar Analyzers for C# and VB") and from the Wintellect Roslyn Analyzers. The flick beneath shows these rules and the two "Rule repositories".

I work on a project, and commit my changes. There is only ane alert in Visual Studio. I believe that I'm skillful to go.

image

When the continuous integration build has completed and the SonarQube analysis is done, I click on the "analysis results" link in the build summary to navigate to the SonarQube project dashboard where I get a sense of the quality of my projection. I decide to dig into the issues and I notice that at that place are many errors, and in particular severe errors (15 critical, in C#). I dig into these errors, to empathize more nearly them, and in particular who introduced them, and … I discover that information technology was me.

That's annoying! I really don't want to have my name here, in item because the whole squad is watching the dashboard. Now you can imagine my frustration since in Visual Studio, I could only run across one warning. I know that this is possible in VS 2015 to be notified of bug as I type them, equally in that location is but-in-time static analysis provided by Roslyn analyzers. That'southward what I want: exist notified of the issues that matter for my team or organization, every bit I introduce them, in the IDE

Why exercise nosotros get dissimilar results?

At that place are 2 causes to these differences between the issues reported in the build and in the IDE.

  • the Roslyn analyzers which are ran are not the same: if I await nether the References | Analyzers node of each project in the Visual Studio solution, I run into that they are empty.

    Whereas in SonarQube, we take seen that our team had installed several plug-ins for Roslyn analyzers and we have activated rules in the quality profile.

    Notation that most analyzers also come equally a VSIX, but to get consistent results every team member must install the correct versions of the right VSIXes on their machine.

  • Even if the right analyzers or the correct VSIXes had been added, that would not solve the consistency trouble. Indeed, the rulesets would need to exist configured to match the rules that are activated in the SonarQube quality profile.

The solution would exist for my squad to add the correct Roslyn analyzers to every project in the solution, and configure the rulesets for these so that they match the Quality profile. Only this is deadening, error prone, and needs to be washed on each projection. Also when the quality contour changes in SonarQube, we would need to update each projection of each solution that should match this quality profile.

Nosotros really need some automation here!

The "SonarQube connected mode"

Released office of SonarLint for Visual Studio ii.0 and to a higher place

Fortunately, we added a new "Visual Studio connected fashion for SonarQube" part of SonarLint for Visual Studio 2.0.

SonarLint for Visual Studio has been releasing regularly both as a VSIX, and a NuGet package. Then far it merely contained SonarSource'due south analyzers, which were recently renamed "Sonar Analyzers for C# and VB". From SonarLint for Visual Studio 2.0, the Visual Studio extension (VSIX) now besides offers an experience in Visual Studio which reconciles the programmer alive experience with the SonarQube quality profile. The NuGet package nevertheless only contains the analyzer.

How to bind your Visual Studio solution to a SonarQube project?

This connected mode brings two new commands, and a new Tab in Squad Explorer.

To bind your Visual Studio solution to a SonarQube go to the Solution context menu, and in the Analysis sub menu, use the new command "Manage SonarQube Connections". The same command is too available from the Analyze pinnacle-level menu.

Clicking on one or the other of these commands, opens the "SonarQube" tab in the Team explorer

By clicking on the Connect … link, you become a dialog where you lot tin can enter the URL for your SonarQube server. Then you enter the credentials to practice an analysis. On the picture below, my SonarQube server is a SonarQube 5.4, and so I created an analysis token, which I'm using equally my login, leaving the password empty (This is the recommended way as this avoids countersign to be sent through the network, also these tokens are revocable). I could also take used a login/password.

As y'all printing Ok, Visual Studio connects to the SonarQube server with the provided credentials, and it retrieves the list of SonarQube projects on this server. You tin then double-click on one of these projects, or Right click and use the "bind" button, to demark your Visual Studio solution to this SonarQube projection

If at that place are outstanding changes in your solution you volition exist prompted to save them first. Y'all might want to cheque that in that location are no local changes that haven't been committed to source command before binding, as this will make it easier to see the changes that are made by the binding process

Equally y'all've done that and observe the progress bar yous will notice that 2 things happen:

  • NuGet packages are installed on each project. These are the Roslyn analyzers which have agile rules in the quality profile of the bound SonarQube project.
  • Rulesets are synthetized from this quality profile and applied to each projection

Immediately you start seeing new warnings appearing in the Mistake Listing. You at present take, in the Visual Studio solution, the same bug as the ones which are reported in SonarQube. At least for C#.

How is your solution affected?

You notice that some things have changed in your Visual Studio solution:

  • A common ruleset was created and added a solution item. It's named from the identifier of the SonarQube projection and the language (blmCSharp.ruleset in that case). It contains the aforementioned issues as the quality profile.
  • An empty ruleset was generated for each projection that references the mutual ruleset. If your project already specifies a ruleset then the existing ruleset volition be updated to include the mutual ruleset (that's my case here)

We take fabricated the choice of non having the project directly reference the common ruleset, so that you are able to edit the project'southward ruleset in the case you want to strengthen information technology. This won't modify the common generated ruleset, but will add entries in the project's ruleset to override it.

The required Roslyn analyzers were also provisioned on each projection.

If you close Visual Studio, and and then reopen the solution, the bounden will nonetheless be here (going to the "SonarQube" tab in the Team Explorer will prove you the same thing).

Y'all tin now commit the changes, and all the members of you team will at present benefit from the exact experience, without having to install any VSIX. Everybody will share the same definition of the quality, and that's the aforementioned as what is divers in SonarQube.

What if the SonarQube quality profile changes later?

If someone in the organization changes the quality profile in SonarQube, you can go to the Team Explorer and use the contextual command on the SonarQube project to re-sync the definition of the quality. Roslyn analyzers will be provisioned as needed, and rulesets updated. That's all the same a manual process for the moment, merely we'll improve this (see "Current limitations" beneath)

If you wish, you can also right click on the SonarQube server in the Team explorer to remove the binding (disconnect), and possibly to demark the solution to a different SonarQube projection.

Current limitations

The connected mode in SonarLint for Visual Studio two.0 is a showtime iteration, and there are still a few crude edges. In future versions of SonarLint for Visual Studio, we will solve the following:

  • The Roslyn analyzers NuGet packages are currently applied on every project, including those which were excluded from the SonarQube analysis, and the exam projects.

  • If you are using TfVC and are working with a server workspace, the experience will fail. To work effectually this, you volition need to:

    • Check out the files in your solution
    • Demark your solution to a SonarQube projection as explained
    • Add together the actress files which were added.
  • You lot are free to change the rulesets for each project manually, and we don't warn you nevertheless if yous loosen the quality past removing rules. In a hereafter release, we'll warn you if that'due south the case
  • It's upwards to yous to re-sync the SonarQube project. In a future release, we'll warn you if the solution is no longer in sync with the SonarQube quality contour.

In closing

We look forward to hearing from you lot. Please transport us your feedback by request some questions on StackOverflow or directly past reporting any bugs you detect on the SonarQube Google Group. You can also submit suggestions for new features, for example, on User Phonation.