Rules and languages
The rules and languages supported by SonarQube for Visual Studio.
The Sonar rules catalog is the entry point where you can discover all the existing rules. While running an analysis, SonarQube for IDE raises an issue every time a piece of code breaks a coding rule. Software quality classification and severity show the impact of the issue on your code. To see a full list of Sonar rules, check the Rules page of your SonarQube Server instance or in your SonarQube Cloud organization.
See the Software qualities page for more information about these classifications.
Overview
SonarQube for Visual Studio currently supports the following programming languages:
Supported out of the box: SonarQube for Visual Studio automatically checks your code in these languages and formats.
Connected Mode required: Running in Connected mode with SonarQube unlocks analysis for these languages and formats.
C rules
C# rules
C++ rules
CSS rules
HTML
JavaScript rules
Secrets detection rules
Text
TypeScript rules
T-SQL
VB.NET rules
The following code analyzers are included with the SonarQube for Visual Studio extension: Sonar C#, Sonar VB.Net, Sonar C-Family for C or C++, and SonarJS.
There are commercial-level rules available in SonarQube Cloud (all plans) and SonarQube Server. For these rules to appear in SonarQube for IDE, it must be in connected mode. See Commercial-level rules for more information.
For more details about languages and new features under consideration for the Visual Studio IDE, you can refer to the SonarQube for IDE roadmap where we list all of our coming soon and newly released features.
Sonar Rule Descriptions
SonarQube for Visual Studio can access descriptive and educational content associated with each issue. Simply select the issue’s rule, as shown below, to open the SonarQube Rule Help view and view the rule descriptions.
In addition, you can access the detailed rule description directly from an issue in the Error List, using the Show Error help option on the contextual menu.

The SonarQube Rule Help view brings rule descriptions and patch instructions relevant to the library or framework you’re using, directly into the IDE. The rule descriptions include a brief explanation of the rule as well as Noncompliant and Compliant code samples.
Users can visualize a diff view for the non & compliant code samples, which should help you fix your issue. Note that diff highlighting is only available for rules descriptions migrated to the new format, and we’re progressively migrating all existing rules to the new format.

An issue’s code quality attribute, software qualities, and severity are presented to you when opening the SonarQube Rule Help view. Below the rule title, you will find the coding attribute labels that highlight an issue’s classification. Check the SonarQube glossary for details about coding attributes, and the Software qualities page to better understand how they help classify your issue.

When in Connected Mode
If you’re running SonarQube for Visual Studio while in connected mode with SonarQube Server or SonarQube Community Build, your view will change according to the server settings. Standard Experience mode encompasses the use of rule types such as bugs, code smells, and vulnerabilities. Alternatively, if SonarQube Server is set to Multi-Quality Rule mode, you will more accurately represent the impact an issue has on all software qualities.
Please see the pages about the MQR mode and Standard Experience for detailed information about the available rule modes for your instance:
Choosing a mode for your instance in SonarQube Server
Choosing a mode for your instance in SonarQube Community Build
Be sure to check out the Investigating issues page for more details about how issues appear in your IDE.
Language-specific requirements
See the Language-specific requirements article on the Requirements page.
Other rule types
Using Sonar rules
When not running in connected mode (also known as standalone mode), all Sonar rules for your language can be configured in the IDE. In addition, some Sonar rules have parameters that you can modify. Here are a few reasons you might want to edit a rule locally:
Disable a rule that is enabled by default. Maybe the rule doesn't apply to your specific project. See Rule selection for more information.
Enable a rule that is disabled by default. By reviewing which rules are disabled, you might notice that some rules could be useful in the context of your project. See Rule selection for more information.
To improve a rule. In some cases rules have parameters. For example, regarding cognitive complexity, you can customize the threshold at which the rule will raise issues. See Edit rules for more information.
Rule selection
The rules can be enabled and disabled locally; see Edit rules below, for details. It is not currently possible to suppress individual issues.
When your project is bound to SonarQube Server or SonarQube Cloud using Connected mode, the rule set is managed on the server side as defined by the quality profile. See Rules while in Connected Mode, for details.
Edit rules
To edit a rule in SonarQube for Visual Studio, navigate to Extensions > SonarQube > Options and select Edit Settings to open the settings.json file located at C:\Users<USER>\AppData\Roaming\SonarLint for Visual Studio. See the settings.json file format and location article below for details.
Requirements and limitations
The settins.json file is only applied while running in standalone mode. Not all rule options, such as changing the severity or customize rule parameters, are supported for all languages. The table below outlines what is supported in which version:
C
4.13
Supported
Supported in v4.13-7.2
Supported
C++
4.13
Supported
Supported in v4.13-7.2
Supported
CSS
8.0
Supported
Not supported
Supported in v8.2 and newer
Secrets detection
6.4
Supported
Not supported
Not applicable
C# and VB.NET
8.16
Supported
Not supported
Supported
Disabling a rule
To disable a rule, either edit the settings.json file as described below or select an instance of the rule in the Error List, right-click on it, and choose the Disable rule command on the context menu:

settings.json file format and location
You can view and change the current rule settings by selecting Edit rules settings from the Extensions > SonarQube > Options window. Selecting Edit setting will open the settings.json file:

The settings.json file records your rule settings and is stored in your user’s roaming profile %APPDATA%\SonarLint for Visual Studio. It applies to all supported versions of Visual Studio. If the machine is domain-joined, then the settings file will be automatically copied to any other machine in the domain that the user logs on to.
See this example as a format sample of your settings.json file. It changes the parameters on a few rules, and at the end, excludes any files matching *Interface.cs plus everything in the org/sonar/* directory.
The format of the rule key in the file is [c|cpp|javascript|typescript]:[rule id]. A list of Sonar rules is available on the Rules page of your SonarQube Server instance or on the Rules page of your SonarQube Cloud organization.
If the settings file does not contain an entry for a rule then the default setting for the rule in the Sonar way quality profile will be used.
When your project is bound to SonarQube Server or SonarQube Cloud using Connected mode, the rule set is managed on the server side as defined by the quality profile. See Rules while in Connected Mode for more information.
Toggling rules
When the rule settings are changed (either by using the Disable rule command or by directly editing and saving the settings.json file), SonarQube for Visual Studio will automatically re-analyze all open documents. The SonarQube for Visual Studio Output window tab will present a text output describing the processing that has taken place; see this example:

Unsupported rules
Some rules are simply too advanced to run locally, in SonarQube for IDE. Because some rules report issues at the project level, apply to the architecture of your code base, or require extensive resources to analyze, they are not included when SonarQube for IDE runs an analysis. Unsupported rule types include architecture, injection vulnerabilities, and some advanced bug detection rules.
However, these advanced issues will be reported in the IDE when you are running in connected mode with SonarQube. See these links for more information:
Sonar https://app.gitbook.com/s/B4UT2GNiZKjtxFtcFAL7/architecture in SonarQube Cloud
Injection vulnerabilities in SonarQube for VS Code
Rules while in Connected Mode
Connected Mode syncs your SonarQube Server or SonarQube Cloud Quality Profile with the local analysis to suppress issues reported in the IDE. Therefore, when running in Connected Mode, SonarQube for IntelliJ will ignore rule settings that are defined locally. See the Connected mode page for more information about running connected mode and the Benefits it brings when working in teams.
Edit rules in connected mode
If you’re running in Connected mode with SonarQube, you can share customized active rules with your team because you’ll all be using the same quality profile to share rule sets. Please see the relevant instructions for the server you are connecting to:
Understanding quality profiles in SonarQube Cloud
Understanding quality profiles in SonarQube Server
Understanding quality profiles in SonarQube Community Build
Rule severities
The Sonar rule severity defined by SonarQube are different than the severities defined by Visual Studio. The mapping from Sonar severities to Visual Studio severities are as follows:
Low
Message
Medium
Warning
High
Warning
If you are using connected mode, the rule severities defined in the quality profile will be used. See the Customizing a software quality severity level article in SonarQube Server page for information about its classification structure.
Last updated
Was this helpful?


