Page Item: Connected Mode

SLUG: team-features-connected-mode

FROM VS_CODE:

You can connect SonarLint to SonarQube 7.9+/SonarCloud by binding your VSCode workspace folder to your SonarQube/SonarCloud project(s), and benefit from the same rules and settings that are used to inspect your project on the server. SonarLint in VSCode then hides Won’t Fix and False Positive issues in any file from a bound folder. In version 3.10 and above, SonarLint for VSCode tries to automatically detect the remote project to bind with your locally opened workspace folder.

While in Connected Mode, SonarLint receives notifications from SonarQube/SonarCloud about your Quality Gate changes and new issues. Notifications can be enabled or disabled from the UI while creating or editing the connection settings. Note, Connected Mode notifications are not available in SonarQube Community Edition 8.6 and earlier.

FROM ECLIPSE:

You can connect SonarLint to SonarQube >= 7.9 or SonarCloud to aim at having consistent issues reported on both sides.

Features when connected mode is used:

• use the same analyzers than the server, assuming they are supported in SonarLint (except for JS/TS and HTML analyzers where SonarLint keep using its embedded version)
• use the same quality profile (same rules activation, parameters, severity, ...)
• reuse some settings defined on the server (rule exclusions, analyzer parameters, ...)
• automatically suppress issues that are marked as Won’t Fix or False Positive on the server

Note: connected mode does not push issues to the server. Rather, its purpose is to configure the IDE so that it uses the same settings as the server.

FROM INTELLIJ

You can connect SonarLint to SonarQube >= 7.9 or SonarCloud to aim at having consistent issues reported on both sides.

Features when using Connected Mode:

• use the same quality profile (same rules activation, parameters, severity, ...)
• reuse some settings defined on the server (rule exclusions, analyzer parameters, ...)
• automatically suppress issues that are marked as Won’t Fix or False Positive on the server
• review a Security Hotspot by clicking on the 'Open in IDE' button on SonarQube
• display taint vulnerabilities that have been found on the server (there is currently no local detection of those advanced issues)
• use the same analyzers as the server, assuming they are supported in SonarLint (exception for C# and C/C++ analyzers where SonarLint keep using its embedded version)

Note: Connected Mode does not push issues to the server. Rather, its purpose is to configure the IDE so that it uses the same settings as the server.

Select the tab (collapsable box) below corresponding to your IDE:

COULD BE INTEGRATED INTO THE ABOVE OVERVIEW

Lorum ipsum

tabbed

PLACE ECLIPSE CONTENT HERE TO ENTERED INTO THE KONTENT.AI-SPECIFIC ASSET

tabbed

H3: Branch awareness SonarLint’s Branch awareness attempts to find the best matching branch from the server to align your code with the most recent analysis. SonarLint for IntelliJ only supports git with regard to branch matching, using the git4idea client shipped by JetBrains.

It is important that we know on which branch the user is at that moment in order to sync the active file with the server when using Connected Mode. When binding your project to the server, SonarLint suppresses issues as defined by the server to know if they have been marked as “won’t fix” for example.

tabbed

PLACE VISUAL STUDIO CONTENT HERE TO ENTERED INTO THE KONTENT.AI-SPECIFIC ASSET

tabbed

Branch awareness is currently not available for Sonarlint in Visual Studio.

This feature will only work when SonarLint is connected to SonarCloud or to a SonarQube server.

In Connected Mode, SonarLint synchronizes some data from the issues that were found on the server side, most importantly the status and resolution. Branch awareness allows SonarLint to consider the branch currently checked out in the IDE and synchronize with the most appropriate branch from the server.

Sonarlint shows the name of the branch that is used as reference for issues synchronized in the IDE's status bar. In the picture below, the checked-out git branch is named "current_branch", and the analyzed branch on the SonarQube server is named "branch_to_analyze".

1. If the branch that is currently checked out locally was analyzed on the server, SonarLint will pick this branch for synchronization. You commonly have a master|main branch analyzed on the server, so if you check out this branch locally, the reference branch will be the same. Important detail: branches with the same names are considered the same branch.
2. If the current branch was not analyzed, SonarLint will try to climb up on the git tree checking if the parent or grandparent branch was analyzed, all the way up to master. This case is illustrated in the picture above: branch_to_analyze was analyzed on the server, and it is the parent branch for current_branch.
3. All other cases will lead to defaulting to the branch marked as "main" on the server, either explicitly (displaying it on UI) or implicitly (without displaying Sonarlint branch UI at all). The latter can happen in case of errors related to local git repository access.

In the project overview, click on the highlighted drop-down list, and you will see a list of analyzed branches and pull requests (see screenshot below for SonarQube).

Currently, this feature does not support synchronization with pull request analysis.

tabbed

PLACE ECLIPSE CONTENT HERE TO ENTERED INTO THE KONTENT.AI-SPECIFIC ASSET

1. Open the connection wizard, for example using menu File -> New-> Other... and then SonarQube/SonarCloud Connection:

2. Select SonarQube and click on the Next button:

3. Enter your SonarQube server URL:

4. Choose the authentication method:

• Token: generate a token on SonarQube, to be used by SonarLint as authentication method. This is the preferred way to avoid the risk to compromise your username/password.
• Username + Password: use directly your SonarQube credentials (not recommended)

5. Enter your token or username/password

6. Give your connection a name

4. Generate a token on SonarCloud, to be used by SonarLint as authentication method.

Configured connections can be retrieved from the Bindings view (Window > Show View > Other... > SonarLint > SonarLint Bindings).

This should open a view at the bottom, listing all connections:

A right-click on a connection will open a contextual menu to remove or edit the connection. It can be useful for example to update the credentials if they have changed.

tabbed

PLACE INTELLIJ CONTENT HERE TO ENTERED INTO THE KONTENT.AI-SPECIFIC ASSET

A connection provides the set of information needed to communicate with the SonarQube server or SonarCloud (URL, credentials, ...).

1. Open IntelliJ settings, find the Tools > SonarLint entry, and select + to open the connection wizard:

   

2. Enter a name for this connection, select SonarCloud or SonarQube. For the latter, you will need to enter the server URL:

   

3. Choose the authentication method:

• Token: generate a token on SonarQube or SonarCloud for SonarLint to use as an authentication method. This is the preferred way to avoid the compromise of your username/password.

• Username + Password: this method can be used for a SonarQube connection only. It lets you use your credentials directly (not recommended)

  

4. For SonarCloud only, select the Organization that you want to connect to (you can also select a public one):

   

5. SonarQube and SonarCloud can push notifications to developers. You can decide whether or not to subscribe:

   

6. Validate the connection creation by selecting Finish at the end of the wizard:

   

7. Save the connection in global settings by clicking OK:

   

Once the connection is established, you can use it to bind your IDE project to a SonarQube/SonarCloud project.

1. Open IntelliJ settings, find the Tools > SonarLint > Project Settings entry:

   

2. Select Bind project to SonarQube/SonarCloud and choose the previously created connection name in the dropdown list

3. Enter the project key as it is configured on SonarQube/SonarCloud. You can also select it by using Search in list...:

   

In IntelliJ additional modules can be imported into a project, e.g. via the 'Project Structure' menu. This is often used for example to group together the back-end and the front-end parts of an application into the same project. As those components might be analyzed separately, SonarLint lets users bind modules to different projects.

1. In the IntelliJ settings, find the Tools > SonarLint > Project Settings entry

2. Make sure a binding is configured at the project level (see the previous section). Note: this will be the default binding for all modules that have no overridden binding.

3. In the 'Override binding per module' section, click on the + sign and choose the module

   

THIS SECTION REQUIRES HARDENING

Observing different analysis results between SonarQube/SonarCloud and SonarLint can have different causes:

1. Third-party analyzers are not executed in SonarLint

   Some issues may be reported in SonarQube by a plugin leveraging a third-party analyzer (PMD, Checkstyle, ESLint, PyLint, …). SonarLint will only run rules from SonarSource analyzers including custom rules extending SonarSource analyzers. Third-party analyzers usually have their own IDE integration, so we have no plan to run them in SonarLint.

2. SonarSource rules usually don’t report issues on test files

   Each SonarLint flavor has its own way of detecting which file is considered a test source (like a unit test). Most rules are not executed on test sources. See the IDE's specific section to know how SonarLint decides whether a file is production code or test code.

3. “Second level” issues are not reported in SonarLint (rule keys starting by common-xxx)

   Issues that depend on the computation of code coverage or duplications are not reported by SonarLint. They are not compatible with “on the fly” analysis. Finding duplications requires the scanner to analyze the entire project (including sibling modules). Collecting coverage requires that all tests be executed with proper coverage engine configuration. This is currently outside the scope of SonarLint.

4. Security Hotspots are not reported in SonarLint

   They are not issues that can immediately be fixed. Security Hotspots follow a review process that is implemented on SonarQube / SonarCloud side.

5. Taint vulnerabilities are not reported in SonarLint

   Vulnerabilities raised by the Taint Analyzer (SQL Injection, ...) are issues detected in SonarQube commercial editions that are also not detected by SonarLint (rule keys starting with javasecurity, phpsecurity or roslyn.sonaranalyzer.security.cs). Running tainted analysis in the IDE is currently not practical mainly for performance reason.

tabbed

PLACE VISUAL STUDIO CONTENT HERE TO ENTERED INTO THE KONTENT.AI-SPECIFIC ASSET

In Connected Mode, the solution is linked to a project in SonarQube/SonarCloud. See Connected Mode for more information.

Note: Connected mode is currently only supported for C#, VB.NET, and C++ projects. Support for JavaScript and TypeScript will be added in the future - see #770.

You can connect SonarLint to SonarQube >= 6.7 or SonarCloud to benefit from the same rules and settings that are used to inspect your project on the server. SonarLint then hides in VS the issues that are marked as Won’t Fix, False Positive or Fixed.

Note: Connected Mode does not push or pull issues to or from the server. Rather, its purpose is to configure the IDE so that it uses the same settings as the server.

The following languages and Visual Studio project types are supported:

• C# (.csproj)
• VB.NET (.vbproj)
• C++ (*.vxcproj and CMake)
• JavaScript and TypeScript in MSBuild projects or folder workspaces (from SLVS v6.7)

This will display the SonarQube Connections tab:

The SonarQube tab is used for connecting to both SonarQube and SonarCloud. To connect to SonarCloud you should enter https://sonarcloud.io as the SonarQube server URL.

You can connect using either a User Token, or a Username and Password. We strongly recommend using User Tokens. The documentation on creating User Tokens is found here for SonarQube or SonarCloud.

When using a User Token, enter the token in the Username/Token field (in SLVS) and leave the Password field blank.

If you are connecting to SonarCloud, you will also be prompted to choose which of your organizations the project belongs to:

You can also connect to public third-party organizations by entering the organization key in the Other Organizations tab:

To find the organization key for a third-party organization, browse to the project you want to bind to on SonarCloud. The organization key is displayed on the project page:

The final step is to select the Sonar project you want to bind the solution to. Select a project with a double-click or a right-click, and select Bind from the context menu:

SonarLint will then fetch the required settings from the server and create local configuration files.

SonarLint will automatically fetch suppressed issues when the bound solution is opened in Visual Studio, and will periodically check for changes every 10 minutes.

You can manually trigger a fetch by selecting Update in the context menu of the SonarQube tab in the Team Explorer window:

The suppressions will be applied next time an analysis is triggered.

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

Note: there is a known issue in which suppressed issues can still be shown for C# and VB.Net. See SLVS-1005 for more information.

SonarLint will fetch file exclusions when a binding is made or updated and save to a file named sonar.settings.json under the .sonarlint folder. When a bound solution is opened, SonarLint will automatically check whether the server settings have changed. If the settings on the server have changed, SonarLint will warn you about this discrepancy and will ask you to update the binding.

Alternatively, you can manually trigger an update from a context menu of the SonarQube tab in the Team Explorer window:

• Supported Languages: C, C++
• Patterns should start with "**/"
• Multicriteria and Test exclusions are not supported. We only support Global Source File Exclusions, Source File Exclusions and Source File Inclusions.

The local Connected Mode configuration files can get out of step with settings on the SonarQube|SonarCloud servers—for example, the Quality Profile for the project is changed on the server.

SonarLint will automatically check whether the server configuration has changed whenever the bound solution is opened in Visual Studio, and will ask you whether you want to update the local configuration to match:

Alternatively, you can manually trigger an update from a context menu of the SonarQube tab in the Team Explorer window:

There is not an "unbind" command to disconnect a solution from SonarQube/SonarCloud. Instead, simply delete the .sonarlint folder and its contents.

The goal is to have the same issues reported in the IDE as are reported to the server during an analysis run. 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.

ADD LINK TO PREVIOUS VERSIONS SECTION BCZ THERE IS CONTENT FOR SLVS THERE.

tabbed

PLACE VISUAL STUDIO CONTENT HERE TO ENTERED INTO THE KONTENT.AI-SPECIFIC ASSET

When running in Connected Mode with SonarQube 8.6 and above, and browsing a security hotspot, a button will be available offering to open the hotspot in SonarLint (with SonarLint already running in VSCode). Limitation: this feature relies on local communication between your web browser and SonarLint, and consequently is not available in some remote environments such as GitPod, or GitHub CodeSpaces.

Connected Mode will also allow unlocking of your analysis for these languages:

• Apex rules
• PL/SQL rules

When configuring Connected Mode, follow the Connection Setup instructions below.

In v3.8 and above of SonarLint for VSCode, to set up SonarQube/SonarCloud connections, open up a SONARLINT CONNECTED MODE view in VSCode.

Select either Add SonarQube Connection or Add SonarCloud Connection, and complete the fields.

For SonarQube connections, provide your SonarQube Server URL and User Token. For SonarCloud connections, provide your Organization Key and User Token. User Tokens should be generated on the SonarQube/SonarCloud side and pasted in the User Token field.

User Token can be generated using these pages:

• SonarQube - https://<your-sonarqube-url>/account/security/
• SonarCloud - https://sonarcloud.io/account/security/

Connection Name is a friendly name for your connections. In case of multiple connections, it also acts as a connectionId.

In SonarLint for VSCode v3.6 and above, notifications can be enabled or disabled here, or from the UI while creating or editing the connection setting (see next image below). Action buttons in the UI used to edit/delete existing, or create additional connections will be revealed when hovering over each connection.

Select Save Connection and verify that the new connection was set up successfully in the Connected Mode view.

From v3.10, SonarLint for VSCode tries to automatically detect a remote SonarQube/SonarCloud project to bind with the locally opened workspace folder. If the locally opened folder contains a sonar-project.properties or a .sonarcloud.properties file, SonarLint will try to configure the binding with the remote project defined in that configuration file.

If no remote match is found, you will be prompted to configure binding manually as we describe below.

To manually configure a project binding, navigate to the SONARLINT CONNECTED MODE view in the VSCode Explorer and select Add Project for the desired connection.

If your open workspace contains multiple folders, you will be prompted to choose a specific folder.

After selecting the folder, choose the remote SonarQube/SonarCloud project you would like to bind.

Select the desired project and enjoy Connected Mode! You can also edit/delete bindings from the SONARLINT CONNECTED MODE view.

Action buttons in the UI used to edit/delete existing or create additional connections, will be revealed when hovering over each connection.

Please see Connected Mode Setup for previous versions to read the documentation about activating Connected Mode in earlier releases of SonarLint for VSCode.

SonarLint keeps server-side data in local storage. If you change something on the server such as the Quality Profile, SonarLint will automatically attempt to synchronize with configured servers at startup and once every hour and will do its best to synchronize with the most appropriate branch from the server. Additionally, you can trigger an update of the local storage using the "SonarLint: Update all project bindings to SonarQube/SonarCloud" command on the command palette (search for "sonarlint").

tabbed

collapsable ## Configuration for C# and VB projects collapse

When binding to SonarQube/SonarCloud, SLVS generates configuration files that are needed for Sonar C# and Sonar VB.NET analyzers. The following configuration files are generated for each language:

• a .ruleset file that contains the rules configuration corresponding to the Quality Profile (See the Microsoft documentation for Rule sets)
• a SonarLint.xml file which contains the rules parameters for Sonar C# and Sonar VB.NET analyzers.

The configuration files are located under the .sonarlint folder in your solution directory.

Each non-test project under your solution needs to reference all of these files in order to be considered as “correctly bound”. If one of the configuration files is not referenced, the project is considered as unbound and SLVS will prompt you to bind it.

The generated ruleset is specified in the CodeAnalysisRuleSet property e.g.

<PropertyGroup>
  <CodeAnalysisRuleSet>path-to-generated-ruleset.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>

The SonarLint.xml file is referenced as an AdditionalFiles item e.g.

<ItemGroup>
  <AdditionalFiles Include="..\.sonarlint\{language}\SonarLint.xml" />
</ItemGroup>

If SLVS recognizes that the project does not reference the generated .ruleset file, SLVS will reference it using the following logic:

If the project has no CodeAnalysisRuleSet properties, SLVS will create one and point to the generated .ruleset file. So your project will look like this:

<PropertyGroup>
  <CodeAnalysisRuleSet>path-to-generated-ruleset.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>

If the project has a CodeAnalysisRuleSet property that points to a .ruleset file that is located under the project’s directory, SLVS will amend that ruleset to reference the generated .ruleset file. So your project’s ruleset file will look like this:

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="My ruleset" Description="test" ToolsVersion="16.0">
  <Include Path="path-to-generated-ruleset.ruleset" Action="Default" />
  ...

If the project has a CodeAnalysisRuleSet property that points to a .ruleset file that is not located under the project’s directory, SLVS will create a new .ruleset file and place it under your project’s directory. The new ruleset file references your previous ruleset and Sonar’s generated .ruleset file. So the new ruleset file will look like this:

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="SonarQube - Sonar way" ToolsVersion="14.0">
  <Include Path="path-to-generated-ruleset.ruleset" Action="Default" />
  <Include Path="path-to-your-other-ruleset.ruleset" Action="Default" />
</RuleSet>

Yes. The initial binding described above will correctly configure your projects, but you are free to modify this using the standard capabilities of MSBuild e.g. using a Directory.Build.props file, or putting the references in a common targets file that is included in the appropriate projects.

FYI the SonarLint for Visual Studio solution in this repo uses a Directory.Build.props file (see here). It does not contain any project-level rulesets or settings.

See our documentation on how to configure a reference to project rulesets, and Microsoft’s documentation for customizing your build.