Home

Page Item: Home SLUG: index

About SonarLint

SonarLint is an IDE extension that helps you detect and fix quality issues as you write code. Like a spell checker, SonarLint squiggles flaws so they can be fixed before committing code. You can get it directly from your IDE Marketplace and it will detect new bugs and quality issues as you code. SonarLint is available for Eclipse, IntelliJ, Visual Studio, and Visual Studio Code. The languages which are supported vary between IDEs. Please see individual descriptions for more detail.

SonarLint can be linked to SonarQube or SonarCloud instances using Connected Mode to provide additional features. More text is needed here mention IDE specificity per language and see section for detail

Using SonarLint

BE CERTAIN THAT THIS TALKS ABOUT ANALYSIS

Standalone mode

By default SonarLint runs in standalone mode i.e. completely independent of SonarQube/SonarCloud.

Connected Mode

Languages Overview

Lorum ipsum, lorum ipsum.

tabbed

Eclipse

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

(for Java, JavaScript, PHP, Python and HTML)

tabbed

IntelliJ

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

(for Java, JavaScript, PHP, Python and HTML)

tabbed

Visual Studio

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

VS SUPPORTS THESE RULES: (for C#, VB.NET, JavaScript, TypeScript, C and C++)

Check the rules to see what SonarLint can do for you:

By default SonarLint runs in standalone mode i.e. completely independent of SonarQube/SonarCloud. Simply open a project containing C#, VB, C++, JS or TS files.

For C# and VB.Net, new issues will be reported as you type. You do not have to select 'Run Code Analysis' from the 'Analyze' menu - the rules are run automatically. Note: by default, VS is configured to only run Roslyn analyzers on files that are currently open. You can choose to have the analysis run on the entire solution as described in the Microsoft docs, although this is obviously more processor-intensive.

For C, C++, JavaScript and TypeScript, new issues will be reported when you open or save a file. Issues are highlighted in your code, and also listed in the 'Error List'.

You can access the detailed rule description directly from the issue in the Error List, using the Show Error help option on the contextual menu.

collapse

Configuration for C# and VB projects

What configuration does SLVS add to my C#/VB.NET projects when binding to a SonarQube/SonarCloud server?

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.

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.

tabbed