sonarsource/sonar-dotnet

Code analyzer for C# and VB.NET projects

Code Quality and Security for C# and VB.NET

Product	Quality Gate	Coverage
Analyzer
Plugin

Static analysis of C# and VB.NET languages in SonarQube, SonarCloud and SonarLint code quality and security products. These Roslyn analyzers allow you to produce Clean Code that is safe, reliable, and maintainable by helping you find and correct bugs, vulnerabilities, and code smells in your codebase.

Features

• 450+ C# rules and 210+ VB.​NET rules
• Metrics (cognitive complexity, duplications, number of lines, etc.)
• Import of test coverage reports from Visual Studio Code Coverage, dotCover, OpenCover, Coverlet, Altcover.
• Import of third-party Roslyn Analyzers results
• Support for custom rules

Useful public resources

• Project homepage
• Issue tracking
• C# rules
• VB.Net rules

Nuget.org packages

• SonarAnalyzer.CSharp
• SonarAnalyzer.VisualBasic

Integration with SonarQube and SonarCloud

• Analyze projects with SonarScanner for .NET
• Importing code coverage
• SonarQube and the code coverage

Do you have a question or feedback?

• Contact us on our Community Forum to provide feedback, ask for help, and request new rules or features.
• Create a GitHub Issue if you've found a bug, False-Positive or False-Negative.

Get started

• Building, testing and debugging the .NET analyzer
• Building, testing and debugging the Java plugin
• How to re-generate NuGet lock files
• Using the rspec.ps1 script

How to contribute

There are many ways you can contribute to the sonar-dotnet project. When contributing, please respect our Code of Conduct.

Join the discussions

One of the easiest ways to contribute is to share your feedback with us (see give feedback) and also answer questions from our community forum. You can also monitor the activity on this repository (opened issues, opened PRs) to get more acquainted with what we do.

Pull Request (PR)

If you want to fix an issue, please read the Get started pages first and make sure that you follow our coding style.

Before submitting the PR, make sure all tests are passing (all checks must be green).

• We suggest you do not pick issues with the Area: CFG label (they are difficult, can have many side effects and are less likely to be accepted).
• We suggest you do not implement new rules unless they are already specified for C# and/or VB.NET on our rules repository.

Note: Our CI does not get automatically triggered on the PRs from external contributors. A member of our team will review the code and trigger the CI on demand by adding a comment on the PR (see Azure Pipelines Comment triggers docs):

• /azp run Sonar.Net - It will run the full pipeline, including plugin tests and promotion

Join us

If you would like to work on this project full-time, we are hiring!

Custom Rules

To request new rules, Contact us on our Community Forum.

If you have an idea for a rule but you are not sure that everyone needs it, you can implement your own Roslyn analyzer.

• You can start with this tutorial from Microsoft to write an analyzer.
• All Roslyn-based issues are picked up by the SonarScanner for .NET and pushed to SonarQube / SonarCloud as external issues.
• Also check out SonarQube Roslyn SDK to embed your Roslyn analyzer in a SonarQube plugin, if you want to manage your rules from SonarQube.

Configuring Rules

SonarQube / SonarCloud and SonarLint in Connected Mode

Open the rule in SonarQube / SonarCloud, scroll down, and (in case the rule has parameters), you can configure the parameters for each Quality Profile the rule is part of.

Use SonarLint Connected Mode to connect to SonarQube and SonarCloud.

SonarLint

The easiest way is to configure a Quality Profile in SonarCloud.

• Create a dummy repository and analyze it in SonarCloud (it's free for open-source).
• Configure the Quality Profile in SonarCloud for the project you created.
• Then connect SonarLint to that project, and it will download the configuration (ruleset and SonarLint.xml files) locally and update your project based on the Quality Profile.

Standalone NuGet

The rules from standalone NuGet packages can be enabled or disabled in the same way as the other analyzers based on Roslyn, by using the .globalconfig or .editorconfig files. See: https://learn.microsoft.com/en-us/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2022#set-rule-severity-in-an-editorconfig-file

If the rules are parameterized, the parameter values can be changed using SonarLint.xml additional files.

The first step is to create a new file, named SonarLint.xml, that has the following structure:

<?xml version="1.0" encoding="utf-8"?>
<AnalysisInput xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Settings>
    <Setting>
      <Key>sonar.cs.analyzeGeneratedCode</Key>
      <Value>false</Value>
    </Setting>
  </Settings>
  <Rules>
    <Rule>
      <Key>S107</Key>
      <Parameters>
        <Parameter>
          <Key>max</Key>
          <Value>2</Value>
        </Parameter>
      </Parameters>
    </Rule>
  </Rules>
</AnalysisInput>

Then, update the projects to include this additional file:

<ItemGroup>
  <AdditionalFiles Include="SonarLint.xml" />
</ItemGroup>

Internal resources

Build configuration

• VM Images repository
• Provisioning repository
• Azure Pipelines
• Peachee configuration

License

Copyright 2014-2024 SonarSource.

Licensed under the GNU Lesser General Public License, Version 3.0

sonar-dotnet's Issues

Do not execute Coverage Sensor on non C# projects

When analyzing for instance a JS project, and when the C# plugin is installed, we can see in logs:

[INFO] Sensor Coverage Report Import
[INFO] Sensor Coverage Report Import (done) | time=0ms
[INFO] Sensor Coverage Report Import
[INFO] Sensor Coverage Report Import (done) | time=0ms
[INFO] Sensor Unit Test Results Import
[INFO] Sensor Unit Test Results Import (done) | time=1ms

• First issue is that it is not obvious that this is coming from the C# plugin.
• Second issue is that it looks Coverage report sensor is executed twice (while in fact it is once for UTs and once for ITs)
• Last issue is that the Sensor should probably not appear in logs when project do not contains any C# file (or VB.NET when it is used in the VB.NET plugin)

Initial ticket: SONARCS-641

Rule S2365 - Properties should not make collection or array copies

Implements RSPEC-2365

Contributes to MMF-820

Fix 1450: False positive in VS2017 but not VS2015

The following code raises a warning (S1450) within VS2017 but not VS2015. We need to investigate what's creating this behavior and then fix it.

public class PrivateFieldUsedAsLocalVariable
{
  private readonly string _a; // FP - S1450

  public PrivateFieldUsedAsLocalVariable(string a)
  {
    _a = a;
  }

  public string GetValue()
  {
    return _a;
  }
}

Feed metric 'executable_lines_data' when SQ >= 6.2

As a replacement of the "force coverage to zero" feature, the plugin should provide for every executable file a measure that will tell platform what are executable lines (ie lines to cover by tests).

Note that the metric was introduced before 6.2 but due to an issue, measure should only be provided when runtime is 6.2+.

Contributes to MMF-739

Update S1144: Rule should handle unused internal types

The current implementation only raises an issue on private unused types but should also raise an issue on internal ones The proposed approach is to effectively raise on unused internal types but to skip types where the assembly defines at least one InternalsVisibleToAttribute attribute.

RSPEC also needs to be updated.

Contributes to MMF-820: SonarC#: fill the gap with FXCop (Step 4)

Implements RSPEC-1144: Unused "private" methods should be removed

Fix S2372: Rule should not raise an issue on properties throwing NotImplementedException

The following code raises but should not:

public DateTime RevisedDate
{
    get
    {
        throw new NotImplementedException();
    }
}

Implements RSPEC-2372.

Initial thread: SONARCS-715

Update S1144: improve messages to better suggest what's expected to be removed.

In Visual Studio Output and Error List windows it is not obvious what member should be removed. The messages should include the type and the name of the member:

Remove the unused private constructor 'Foo'
Remove the unused private field 'xxx'
Remove the unused private method 'Bar'

Rule S3971: "GC.SuppressFinalize" should not be called

Implements RSPEC-3971: "GC.SuppressFinalize" should not be called

Contributes to MMF-820: SonarC#: fill the gap with FXCop (Step 4)

Update rule 'Neither DES nor DESede should be used' to include RC2

This encryption algorithm should also be avoided

Relates to RSPEC-2278 Neither DES (Data Encryption Standard) nor DESede (3DES) should be used

Rule S1994 (for loop increment) - update to focus on misplaced increments

This rule has been re-worked to focus on increments that happen only outside of the expected location. To cover the bug aspect this rule used to have, #199 has been entered to implement RSPEC-2189

Ability to associate several rules to one single DiagnosticAnalyzer

We start having some rules which closely relate to each other relate either because they are raising very similar issues (see #165) or because they depends upon the same engine (see #176 Symbolic execution engine should be executed once and only once).

In both cases, the capability to have one DiagnoticAnalyzer covering several rules would be a perfect solution.

Rule S3346: Expressions used in "Debug.Assert" should not produce side effects

Implements RSPEC-3346

Fix S2583: Rule should consider Nullable<bool> values

The following code generates a false positive:

bool? x = null;
if (x == true)
{
}
else if (x == false) // FP
{
}

Rule S3915: Conditions should not unconditionally evaluate to "false"

This rule is the result of the split of RSPEC-2583.

Implements: RSPEC-3915

Deprecate sonar.cs.msbuild.testProjectPattern

We should deprecate this property, changing the display message.
In the future, the property should be removed and no longer be exposed in SonarQube.

'sonar.msbuild.testProjectPattern' should be passed directly to the Scanner for MSBuild.

Relates to SONARMSBRU-285 Replace 'sonar.cs.msbuild.testProjectPattern' with 'sonar.msbuild.testProjectPattern' without default value

Rule S3963: "static" fields should be initialized inline

Implements RSPEC-3963: "static" fields should be initialized inline

Contributes to MMF-820: SonarC#: fill the gap with FXCop (Step 4)

Symbolic execution engine should be executed once and only once

For the timebeing, each rule based on dataflow analysis executes by itself the symbolic execution engine, so 5 rules -> 5 executions and tomorrow 15 rules -> 15 executions. This will quickly lead to a big performance hotspot.

The solution might depends upon our ability to associate several rules to one DiagnosticAnalyzer (depends upon #177).

Update S2070: the rule should include a longer list of deprecated hash algorithms

DSA, HMAC-MD5, RIPEMD160, and HMACRIPEMD160 have been added to the specification for this rule.

Implements RSPEC-2070.

Rule S2681: Expand implementation for additional patterns

This rule implementation should also catch the following patterns:

if(condition) firstActionInBlock(); secondAction();  // Noncompliant; secondAction executed unconditionally

if(condition) firstActionInBlock();  // Noncompliant
  secondAction();  // Executed unconditionally

Update rule 'SHA-1 and Message-Digest should not be used' to include longer list

DSA, HMAC-MD5, RIPEMD160, and HMACRIPEMD160 have been added to the specification for this rule.

Relates to RSPEC-2070 SHA-1 and Message-Digest hash algorithms should not be used

Rule: S2189 detect infinite loops

Should implement RSPEC-2189

Update S2278: The rule should include a longer list of deprecated encryption algorithms

Update the rule to include RC2.

Implements RSPEC-2278.

Rule S3925: "ISerializable" should be implemented correctly

Implements RSPEC-3925 "ISerializable" should be implemented correctly.

Contributes to MMF-820 SonarC#: fill the gap with FXCop (Step 4)

Update S101: A special case should be made for two-letter acronyms in which both letters are capitalized

As mentioned in the official Microsoft "Capitalization Conventions" guidelines:

A special case is made for two-letter acronyms in which both letters are capitalized, as shown in the following identifier: IOStream

This special case must be supported out of the box.

Relates to RSPEC-101 Class names should comply with a naming convention

Fix S1871: "Branches with same implementation" should ignore single line blocks

Implement RSPEC-3923 to find conditional structures where all branches are the same, and update the implementation of RSPEC-1871 to

• not raise issues on such cases
• respect the newly added exception:

Blocks in an if chain that contain a single line of code are ignored, as are blocks in a switch statement that contain a single line of code with or without a following break.

Fix S1121: Assignments should not be made from within sub-expressions' should ignore chained assignments

For instance, an issue is raised here and should not be:
cPos = curLineStart = 0;
Why? Because this is a not-uncommon practice, and the intent is clear and should not confuse maintainers. Additionally, there's not a lot to be gained by updating it to:

i = 0;
j = 0;

and it would perhaps be a regression in terms of readability to update it to

i = 0;
j = i;

Implements RSPEC-1121

Rule S3967: Multidimensional arrays should not be used

Implements RSPEC-3967: Multidimensional arrays should not be used

Contributes to MMF-820: SonarC#: fill the gap with FXCop (Step 4)

Rule S3928: Check ArgumentException instantiations for argument names

void Method(int a, int b)
{
    throw new ArgumentException("My error message", "c"); // Noncompliant 
    throw new ArgumentException("My error message", "c", innerException); // Noncompliant 
    throw new ArgumentException("a", "My error message"); // Noncompliant
    throw new ArgumentException("My error message", "a"); // Compliant
    throw new ArgumentException("My error message", "a", innerException); // Compliant
}

See https://msdn.microsoft.com/en-us/library/2ek3h5bz(v=vs.110).aspx

See https://code-cracker.github.io/diagnostics/CC0002.html

Implements RSPEC-3928

Fix S3247: Rule should not report on is + cast for ValueTypes

While correct for casting a reference type to another reference type, when casting a reference type to a ValueType (common when overriding Equals) is more complex to implement and is actually slower.

Protobuf files should use OS casing constraint for paths

Since default windows file system is not case sensitive, path to projects may not have the same character case in VS project configuration and in the file system.

In such case, the ".pb" files that are generated during the execution of MSBuild uses path to source files that are not matching exactly the file system.

It impact the SonarQube analysis because the link between the information contained in these ".pb" files and the sources files is broken.

To reproduce:

• create a solution and a project
• the case of some folders / file names in the file system
• run the analysis of your solution

Add support for pattern matching in conditions in CFG

Code like this should be correctly analyzed

public void Patterns(object o)
{
    if (o is null)
    {
        return;
    }

    if (o is int i)
    {
        Console.WriteLine(i);
    }
}

Apart from if statements, the other language elements that should support pattern matching are:
ternary operators, for loops, while loops, do loops

Switch statements are handled in the referenced ticket #1775

SonarLint for VS with TFS version control not usable

SonarLint 2.11.0 for Visual Studio has severe problems with .ruleset files if TFS is used as the backing version control system (I assume that this is not an issue when using Git). The problems are described in detail in this StackOverflow question.

Rule S3962: "static readonly" constants should be "const" instead

Implements RSPEC-3962: "static readonly" constants should be "const" instead

Contributes to MMF-820: SonarC#: fill the gap with FXCop (Step 4)

Fix S2372: allow throwing some exception types from a property getter

As specified in RSPEC-2372 it's fine to throw some types of exceptions from a getter : NotImplementedException, NotSupportedException or PlatformNotSupportedException

Update S2360: ignore non-public methods

Since this rule is about protecting callers and callers will presumably be focused only on public methods, this rule should ignore non-public methods.

False positive on Nullable<bool> checks S2583

The following code generates a false positive:

bool? x = null;
if (x == true)
{
}
else if (x == false) // FP
{
}

The problem is that we set a true or false constraint on SV_x when a constraint is set on x == true, however there's a third option that the x == true is false due to x being null, and == being the lifted operator.

Fix S1450: Rule should not raise an issue when methods call each other

using System;
class C
{
    private bool f; // Compliant

    public void M1()
    {
        f = true;
        M2(); // M2 modifies "f" and the field cannot be removed
        Console.Write(f);
    }

    public void M2()
    {
        f = false;
    }
}

See RSPEC-1450 and SONARCS-676

Support many coverage reports

In SonarQube 6.2, the concept of coverage type (unit/IT/overall) was dropped. Instead a plugin can save multiple coverage reports (with no specific type) per file. As a result, the plugin should be updated.

When the runtime is SonarQube 6.2+ :

• accept comma separated lists of coverage reports, with no differentiation by type

Contributes to MMF-345

Rule S2365: Properties should not make collection or array copies

Implements RSPEC-2365 Properties should not make collection or array copies

Contributes MMF-820 SonarC#: fill the gap with FXCop (Step 4)

Rule S3900: Arguments of public methods should be validated against null

Implements RSPEC-3900 Arguments of public methods should be validated against null

Contributes to MMF-963

Fix S1144: Unused private members should not report false positives with Unity classes

We should investigate the options:

• whitelist affected classes, such as https://docs.unity3d.com/ScriptReference/MonoBehaviour.html, docs.unity3d.com/ScriptReference/AssetPostprocessor.html
• introduce a whitelist parameter which can be set by the user in SQ. Note that the list might be very long, (I'm not sure if there's a limit in SQ for parameter length), and that this rule should work out of the box with SonarLint with no parameters (at least for non Unity projects).

See SONARCS-677 for the full thread of discussion

Rule S2589: Boolean expressions should not be gratuitous

Implements RSPEC-2589

Coming from a split of RSPEC-2583 "Conditionally executed blocks should be reachable"

Implementing this new rule might require first to fix #177 to make it possible to have the same DiagnosticAnalyzer covering both the detection of RSPEC-2589 and RSPEC-2583

Fix S1451: Rule should handle multiple single-line comments

Currently, the following regex
\/\/[-]*(.|\s)*foobar(.|\s)*

Will not raise an issue against:

//--foobar
//--

But still raises an issue against::

//--
//--foobar

And it shouldn't since the string matches the regex.

Fix S2757: do not raise an issue when no whitespace after the two operators

In the following case and as mentioned in RSPEC-2757 "=+" should not be used instead of "+=" we don't expect to get an issue : a=-b;

No issue should be raised when there is no space after the two operators. Whereas we do expect an issue here : a =- b;

Fix S3236: Rule should no longer report on CallerMemberName

The rule was previously reporting on all CallerMemberName which was leading to a lot of FP for WPF-UWP applications not relying on special notification frameworks.

TODO:

• Update code of the rule
• Update RSPEC metadata

Implements: RSPEC-3236

Fix S1121: Assignments should not be made from within sub-expressions' should ignore chained assignments

For instance, an issue is raised here and should not be:
cPos = curLineStart = 0;

Why? Because this is a not-uncommon practice, and the intent is clear and should not confuse maintainers. Additionally, there's not a lot to be gained by updating it to:

i = 0;
j = 0;
{code}
and it would perhaps be a regression in terms of readability to update it to
{code}
i = 0;
j = i;

Relates to RSPEC-1121 Assignments should not be made from within sub-expressions

Rule S1994 (for loop increment) - update to focus on misplaced increments

This rule has been re-worked to focus on increments that happen only outside of the expected location. To cover the bug aspect this rule used to have, SONARCS-881 has been entered to implement RSPEC-2189

Rule S3966: Objects should not be disposed more than once

Implements RSPEC-3966: Objects should not be disposed more than once

Contributes to MMF-963.

RSPEC-2360 fix "compliant solution"

The rule is "Optional parameters should not be used", yet the compliant solution contains an optional parameter:

void Notify(string company, string office = "QJZ")

I assume it was erroneously copied from the noncompliant example.

Feed Cognitive Complexity metric

Contributes to MMF-733: Calculate Cognitive Complexity metric at file level and above