Connected Mode

Connecting SonarLint to SonarQube or SonarCloud is the first step in setting up the Sonar Solution, to take advantage of having consistent issues reported on both sides. Setting up Connected Mode will permit the transmission of information SonarLint needs, such as URLs and user credentials or file exclusions and marked issues, to communicate with SonarQube or SonarCloud. When binding your local workspace folder to your SonarQube or SonarCloud project(s), SonarLint will try to match, as much as possible, the same rules and settings as found on the server.

While in Connected Mode, SonarLint receives notifications from SonarQube/SonarCloud about your Quality Gate changes and new issues. Smart notifications can be enabled or disabled from the UI while creating or editing the connection settings. 

Setting up Connected Mode is easy and you can easily share your connection setup with your team.  

Benefits

• Analyze more languages and detect more issues by combining Sonarlint’s supported rules with those supported by SonarQube and SonarCloud.
• Highlight advanced issues (in the IDE) like taint vulnerabilities, detected by SonarQube and SonarCloud. 
• Use the same quality profile locally as is defined on the SonarQube or SonarCloud server.  
• Apply settings, such as rule selection and file exclusions defined on the SonarQube or SonarCloud server to your local analysis. 
• Define specific analyzer parameters in SonarQube or on SonarCloud, and have those parameters applied locally.
• Changes in your SonarQube or SonarCloud quality gate will arrive in your IDE when you accept Smart notifications.
• Automatically suppress issues that are marked as Accepted or False Positive in SonarQube or on SonarCloud so that locally reported issues match those found on the server.

Free and open-source versions of SonarQube and SonarCloud are available to work in Connected Mode. In SonarCloud, it’s always free to analyze your publicly accessible projects; paid plans are required only if linking to a private repository.

Prerequisites and supported languages

Having a SonarQube 8.9+ project or a SonarCloud project is required to run SonarLint for Visual Studio in Connected Mode. The following languages and Visual Studio project types are supported:

• C# rules (.csproj)
• VB.NET rules (.vbproj)
• C++ rules (*.vxcproj and CMake)
• CSS rules (from SonarLint for Visual Studio v6.16)
• JavaScript rules and TypeScript rules in MSBuild projects or folder workspaces (from SonarLint for Visual Studio v6.7)

When running SonarLint in Connected Mode with SonarQube, Security Hotspots found in JS and CFamily files will be reported. See the security hotspot page for more details.

Branch awareness

Branch awareness allows SonarLint to consider the branch currently checked out in the IDE and synchronize it with the most appropriate branch from the server; we call this branch matching.

In Connected Mode, SonarLint synchronizes some data from the issues that were found on the server, such as the issue's status and resolution. It is important that SonarLint knows on which branch the user is at that moment in order to sync the local analysis with the correct branch analyzed by the server.

SonarLint for Visual Studio only supports git and the git branch name with regard to branch matching. If the SonarLint’s branch awareness algorithm fails to detect a best match, taint vulnerabilities, and issue suppressions will be pulled from the Sonar main branch by default.

Checking which branches are analyzed on the server

In SonarQube, open the highlighted drop-down list shown below (as it looks in SonarQube) for a list of analyzed branches and pull requests.

To analyze branches other than master|main , please check the SonarQube or SonarCloud documentation about branch analysis.

How SonarLint selects which branch to sync

SonarLint deploys these three methods to choose which branch (in SonarQube or on SonarCloud) to sync with the local analysis.

Exact match

Branches with the same name are considered the same branch. If the branch that is currently checked out locally is analyzed on the server, SonarLint will pick this branch for synchronization. 

Closest branch

SonarLint will consider all local branches that also exist on the server. For each branch, SonarLint will compute the distance between the current HEAD and the branch by the count of commits. The closest branch will be kept. In case the number of commits is the same for two or more branches and the main branch is among them, it will be preferred; else the tie will be broken with a random choice (from the list of equidistance branches).

Default to main branch

All other cases will default to the branch marked as "main" on the server. For example, if there is an error in reading the branch, or if there is no Git repo, SonarLint will default to the main branch.

Long and short-lived branches

When using Connected Mode with SonarCloud, issues on short-lived branches are not synchronized. When an issue is marked in SonarCloud accepted or false positive on a short-lived branch, SonarLint will still show that issue in the IDE.

SonarQube does not distinguish between long- and short-lived branches therefore, all issue resolutions are recognized.

Connection setup

SonarLint for Visual Studio provides a connection wizard to help you set up Connected Mode with SonarQube or SonarCloud. Please see the Connected Mode setup page for detailed instructions.

Sharing your setup

From version 7.4, it is possible to share a setup configuration file with your team, simplifying the process. 

One team member must step through the First-time setup process, then export and commit the binding configuration to the repo. Any team member with project credentials running SonarLint will find the binding details inside of the project’s source folder.

Please see the Connected Mode setup page for detailed instructions.

Project binding

When you bind a project, SonarLint uses the Quality Profile defined on the server to decide which rules to run locally, and which rule parameters to use. When you mark a particular issue as “safe” or “won’t fix” on the server, the corresponding issue will be ignored in the IDE. Check the SonarQube or SonarCloud documentation for details about managing your quality profile.

Local settings

If you are running SonarLint for Visual Studio v6.16 or earlier, please see the Previous versions page for information about how server synchronization is managed. Before v7.0 (released in June 2023), Connected Mode behaved a bit differently; check the Migrate Connected Mode to v7 page for more details.

Types of updates

Quality Profiles

Quality profiles are a key part of using SonarLint in Connected Mode with SonarQube or SonarCloud. SonarLint periodically syncs the project’s quality profile from the server and applies its set of rules during code analysis.

Other types of updates

Suppressed issues

As mentioned above, it is rare that you will need to manually retrieve suppressed issues from the server because SonarLint automatically fetches them when the bound solution is opened. From v6.14, SonarLint supports near-real-time sync of suppressed issues; note that previous releases periodically check for updates every 10 minutes, when a bound solution is opened, or the git branch changes in the IDE.

Issue suppressions are reapplied automatically.

A suppressed issue might still appear in Visual Studio if the code is different from when it was analyzed on SonarQube/SonarCloud.

File exclusions

Defining file exclusions locally in SonarLint for Visual Studio is not yet possible, however, SonarLint will fetch file exclusions from the SonarQube or SonarCloud server when you bind a project or update a binding. These settings are saved to a file named sonar.settings.json. 

Note that in SonarLint for Visual Studio 7.0, the settings file was moved outside of the solution directory; please check the Legacy Connected Mode article on the Previous versions page for information about the settings file in versions 6.16 and older.

For more information about how the SonarLint settings are handled by the server, see the SonarQube or SonarCloud documentation on setting your analysis scope.

Known limitations for file exclusions:

• Supported Languages: C# & VB (.NET support in SonarLint v6.15+), C, C++, CSS, JavaScript, TypeScript, and Secrets.
• Patterns should start with **/
• Multicriteria and Test exclusions are not supported. SonarLint for Visual Studio only supports Global Source File Exclusions, Source File Exclusions, and Source File Inclusions when setting the analysis scope. See the pages about file inclusion and exclusion on SonarQube and SonarCloud in their documentation.

Known issues

The goal is to have the same issues reported in the IDE as are reported on the server. However, there are a number of reasons why a set of issues can be different: some technical, some bugs, or some work that just hasn't been done yet.

See ticket #1336 for a summary of the known issues and their current status.

Extended Rule descriptions

From v6.14 and newer, Extended rule descriptions written in SonarQube or SonarCloud are available in the Sonar Rule Help view container. Because they are written SonarQube or SonarCloud, you must be viewing your project while in Connected Mode.

• You can extend rule descriptions in SonarQube and SonarCloud to let users know how your organization uses a particular rule or give more insight into a rule.
• Note that the extension will be available to non-admin users as a normal part of the rule details.

In your SonarQube or SonarCloud instance, go to the Rule you want to edit in the Rules tab, then click the Extend Description button to open a field box that will accept your Markdown-formatted text. What you add to the rule from your SonarQube or SonarCloud server will be seen in the user’s instance of Visual Studio.

Legacy Connected Mode

Before SonarLint for Visual Studio version 7.0 (released in June 2023), Connected Mode behaved a bit differently:

• In versions 6.16 and earlier, SonarLint saved all of its configuration files inside the solution project folder, and it was up to the user to commit or exclude the Sonar settings. This caused some version control management problems, especially when syncing with the server in Connected Mode. Please check the Previous versions page for important details when running in Connected Mode.
• From version 7.0 and newer, the settings folder was moved outside of the solution directory to the %AppData%\Roaming\SonarLint for Visual Studio\Bindings folder.

Before SonarLint for Visual Studio version 4.0 (released in May 2018), Connected Mode behaved a bit differently:

• The appropriate NuGet package for the SonarAnalyzer.CSharp/SonarAnalyzer.VisualBasic analyzers were added to each project.
• The Connected Mode settings were saved in a solution-level folder called SonarQube in a file called SolutionBinding.sqconfig.
• If you are upgrading to version 7.0 from Sonarlint version 3.10 or earlier, please check the Migrating from a legacy version paragraph for instructions.

In SonarLint for Visual Studio version 4.0 and later:

• The analyzer NuGet packages are no longer installed in any project
• The settings are saved in a solution-level folder called .sonarlint in a file called [solution name].slconfig.

SonarLint-SonarQube version support policy

SonarLint enables users to establish a connection to the latest SonarQube version and to the latest LTA (Long Term Active)version. When a new LTA version is released (approximately every 18 months), we still enable connecting SonarLint to the previous LTS version for a certain period of time (currently 12 months after the latest LTS release) to allow enough time for organizations to upgrade their SonarQube version. 

For more information about long-term support of SonarQube, check out our page describing "what an LTA is" and, to review IDE-specific requirements, please check the respective pages of the documentation as listed in the next paragraph.

⚠️ The 8.9LTA reached its support expiration date (in November ’23).

Notifications

Connected Mode allows SonarQube to send smart alerts to individuals or teams as soon as something appears on the server that something failed, when new issues are discovered or when the Sonar Quality Profile is updated, for example. With everyone in the loop, issues can be addressed promptly, improving the overall software quality and delivery. The notification will include a link to call back to SonarQube or SonarCloud where you can learn more about the issues that were introduced. 

You'll receive smart notifications in your IDE when:

• the quality gate status of a project open in your IDE changes (see the SonarQube or SonarCloud documentation for details about using quality gates in your project)
• a SonarQube or SonarCloud analysis raises new issues that you've introduced in a project open in your IDE

You can activate or deactivate smart notifications in SonarLint on the IDE side on a server-by-server basis.

Sonar Smart Notifications are available in all editions of SonarQube and SonarCloud.

More on how to manage Smart Notifications in SonarLint for Visual Studio will be coming soon...