Was this page helpful?
Previous versions
Please remember that SonarSource officially supports only the latest version of SonarLint for Visual Studio.
Installing previous versions
Installation of an earlier version is possible by downloading the appropriate asset from the Releases page before following the Offline installation instruction.
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.
- From version 7.0 and newer, the settings folder was moved outside of the solution directory to the
%AppData%\Roaming\SonarLint for Visual Studio\Bindingsfolder.
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.VisualBasicanalyzers 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 Migrate Connected Mode to v7 page 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
.sonarlintin a file called[solution name].slconfig.
Connected Mode for C# and VB projects
Legacy binding instructions for C# and VB projects
Connected Mode for C# and VB projects v6.16 and earlier
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
.rulesetfile that contains the rules configuration corresponding to the Quality Profile (See the Microsoft documentation for Rule sets) - a
SonarLint.xmlfile 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.
How does SLVS recognize that the configuration files are referenced?
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>What happens when SLVS binds my C# / VB.NET projects?
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>Can I customize how my projects are configured?
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.
Prior versions v4.13-7.2
Define C, C++, JS, TS or secrets detection rules for local analysis in version 4.13-7.2
In SonarLint for Visual Studio 7.3 and newer, changing the Sonar severity of an issue is no longer possible.
In standalone mode, it is possible to enable or disable rules, configure rule parameters, and in versions 4.13-7.2, change the reported rule severity. Not all options are supported for all languages. See the table below for more information.
Rule management support in versions 4.13-7.2
| Language | From version | Enable/disable | Change severity | Configure rule parameters |
|---|---|---|---|---|
| C | 4.13 | Supported | Supported in v4.13-7.2 | Supported |
| C++ | 4.13 | Supported | Supported in v4.13-7.2 | Supported |
| JavaScript | 4.35 | Supported | Not supported. See #2399. | Not supported. See #2400. |
| TypeScript | 4.35 | Supported | Not supported. See #2399. | Not supported. See #2400. |
| Secrets detection | 6.4 | Supported | Not Supported | Not applicable |
Disabling a rule
To disable a rule, select an instance of the rule in the Error List and select the Disable SonarLint rule command on the context menu:
You can view and change the current rule settings by selecting Edit rules settings from the SonarLint > Tools > Options page:
When the rule settings are changed (either by using the Disable SonarLint rule command or by directly editing and saving the settings.json file), SonarLint will automatically re-analyze all open documents.
The SonarLint Output window tab contains text output describing the processing that has taken place; see this example:
settings.json file format and location
The settings.json file is stored in 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.
The format of the settings file is as follows:
The format of the rule key in the file is [c|cpp|javascript|typescript]:[rule id]. The full list of rules is available at https://rules.sonarsource.com/.
Valid severity values are Blocker, Critical, Major, Minor and Info. Changing the severity of a rule only affects the label in the Category column in the Error List.
If the settings file does not contain an entry for a rule then the default setting for the rule in the SonarWay Quality Profile will be used.
Note: if the solution is in Connected Mode then the settings file is ignored. Connected Mode is not currently for JavaScript or TypeScript - see #770. It is also not available for Secrets detection rules, which are only run in the IDE and so cannot be configured on the server.
Rule severity mapping before v7.2
The Sonar rule severities defined by SonarQube and SonarCloud are different than the severities defined by Visual Studio. The mapping from Sonar severities to Visual Studio severities is as follows:
| SonarQube and SonarCloud | Visual Studio |
|---|---|
| Info | Info |
| Minor | Info |
| Major | Warning |
| Critical | Warning |
| Blocker | Warning |
By default Sonar Critical and Blocker issues are not mapped to Visual Studio Error as this would cause IDE builds to fail. You can change that by enabling Treat warnings as errors in your project properties in Visual Studio. If you are using Connected Mode, the rule severities defined in the Quality Profile will be used.
In SonarLint for Visual Studio 7.3 and newer, changing the Sonar severity of an issue is not possible.
Versions prior to v4.34
This section describes the behavior of SonarLint versions 4.34 or older. Javascript analysis is enabled by default in versions 4.34+.
Out of the box, SLVS will analyze C#, VB.NET, and C or C++. Support for additional languages requires the download of another component, the SonarLint daemon. This simply requires clicking a button in the Tools, Options, SonarLint tab as described below.
The only additional language currently supported is JavaScript, although it is likely this set of supported languages will increase in the future.
Enabling analysis of additional languages
To enable analysis of additional languages, select Tools, Options, SonarLint and click on the "Activate" button then clicking "OK". The SonarLint daemon binaries will be downloaded in the background, with the download progress being shown in the Visual Studio status bar.
Once the download has completed, JavaScript files will be analysed whenever you save them.
Specifying an alternative download location (SLVS v4.11 or later)
By default the additional binaries will be downloaded from the public site https://binaries.sonarsource.com/?prefix=Distribution/sonarlint-daemon/. If you are working in an environment in which developer machines do not have access to the public internet, you can host the required binaries yourself and set the environment variable SONARLINT_DAEMON_DOWNLOAD_URL to tell SLVS where to find the binaries.
There are few restrictions:
- the environment variable SONARLINT_DAEMON_DOWNLOAD_URL must be set before VS starts.
- the URL must be absolute.
- the daemon zip file must not be renamed i.e. it must in the format
sonarlint-daemon-{version}-windows.zip.
Changes to C/C++ analysis in SLVS v4.12
- Prior to SLVS v4.12 C++ was an additional language so C/C++ analysis would only occur if support for additional languages was enabled. Since v4.12 the C/C++ analysis binaries have been included in the SLVS VSIX so the SonarLint daemon is not required. If you were using SLVS to analyze C/C++ prior to v4.12, you no longer need to have support for additional languages enabled unless you also want JavaScript files to be analyzed.
The SonarLint daemon
Most of the Sonar analyzers are written in Java and so need to be run in a Java process. The SonarLint daemon is a Java component that runs in the background and hosts the supported Sonar analyzers. There is no need to have Java installed separately on your development machine - the SonarLint daemon download includes the necessary Java runtime files.
SLVS handles communication with the daemon behind the scenes. Informational messages about the daemon will appear in the SonarLint pane of the Visual Studio Output tool window. Otherwise, the existence of the daemon should be completely transparent to the end user: SonarLint for Visual Studio will take care of starting and stopping the daemon, passing files for analysis, processing the results, and displaying them in the Visual Studio Error List.
The daemon will only be started when you open a file that can be analyzed by the daemon, and it will be closed automatically when you close the solution containing the file (note that this was not the case prior to SLVS v4.12; in older versions of SLVS the daemon would start when VS started).
You can use the Task Manager to check whether the daemon is running:
| Field | Value |
| Process name | java.exe |
| Process description | OpenJDK Platform binary |
| File location | %LOCALAPPDATA%\SonarLint for Visual Studio\sonarlint-daemon-{version}-windows\jre\bin |
© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARLINT, SONARQUBE, SONARCLOUD, and CLEAN AS YOU CODE are trademarks of SonarSource SA.
