Please remember that SonarSource officially supports only the latest version of SonarLint for Visual Studio.
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
- 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
Legacy binding instructions for C# and VB projects
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:
.rulesetfile that contains the rules configuration corresponding to the Quality Profile (See the Microsoft documentation for Rule sets)
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.
The generated ruleset is specified in the
CodeAnalysisRuleSet property e.g.
SonarLint.xml file is referenced as an
AdditionalFiles item e.g.
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:
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:
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:
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.
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.
|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|
|TypeScript||4.35||Supported||Not supported. See #2399.||Not supported. See #2400.|
|Secrets detection||6.4||Supported||Not Supported||Not applicable|
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 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
Valid severity values are
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.
|SonarQube and SonarCloud||Visual Studio|
By default Sonar
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.
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
SonarLint tab as described below.
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.
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
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
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:
|Process description||OpenJDK Platform binary|
© 2015-2023, SonarSource S.A, Switzerland. Except where otherwise noted, content in this space is licensed under the GNU Lesser General Public License, Version 3.0. SONARLINT is a trademark of SonarSource SA. All other trademarks and copyrights are the property of their respective owners. See SonarSource.com for everything you need to know about the Sonar Solution.