C#

C# analysis is available in all editions of SonarQube Server and SonarQube Community Build.

Supported versions

The level of support for a language is defined as follows:

• Fully supported: Analysis will complete. All the language features are understood and examined.
• Supported: Most language features are understood and examined but the version includes unsupported features. Analysis might break or provide incomplete results.

C#1 to C#14: Fully supported

Supported frameworks and tools

ASP.NET MVC, ASP.NET Core MVC

Language-specific properties

Discover and update the C#-specific Analysis parameters in: Administration > Configuration > General Settings > Languages > C#

Analyze generated code

To analyze tool-generated code (e.g. WCF code generated by SvcUtil.exe, protobuf code generated by protoc, Swagger client code generated by NSwag) for a specific C# project, enable the "Analyze generated code" setting inside Project Settings > General Settings > Languages > C#. By default, tool-generated code files are skipped from analysis.

The detection of generated code is based on file name, special comments and attributes. The currently recognized values are in GeneratedCodeRecognizer.cs.

When a Generated comment is present in the file, SonarQube ignores the entire ** file, even if only parts of it were generated. It’s possible to enable or disable analysis of files containing generated code at the instance or project level in General Settings > Languages > Your language > Analyze generated code.

Scanner compatibility

Important: C# analysis requires the SonarScanner for .NET. The SonarScanner CLI doesn't support C# or VB.NET analysis.

To analyze C# code, use SonarScanner for .NET version 5.x or higher.

Exclusions

Files to be excluded should be set in the project configuration. Excluded files are still going to be analyzed during the compilation and the results will be filtered according to the exclusion settings.

As an alternative, an .editorconfig file can be used to disable the analysis for a specific rule on a file or directory. This can solve performance problems on large files.

[Path/File.cs]
dotnet_diagnostic.Sxxx.severity = none

In-line suppression of issues

Standard Roslyn-based suppression mechanisms are available as shown below.

Pragma suppression

#pragma warning disable S2094 // Classes should not be empty S2094
public class Empty { }
#pragma warning restore S2094 // Classes should not be empty S2094

Local SuppressMessage attribute

[SuppressMessage("Major Code Smell", "S2094:Classes should not be empty", Justification = "Because ...")]
public class Empty { }

Global SuppressMessage attribute

// Global Suppression attribute
[assembly: SuppressMessage("Major Code Smell", "S2094:Classes should not be empty", Justification = "Because..", Scope = "member", Target = "~P:SonarAnalyzer.Core.AnalysisContext.Empty.Value")]

Using Visual Studio

The automatic generation of all three suppression mechanisms is supported by standard Visual Studio experience out of the box.

Using SonarQube for Visual Studio

The Pragma suppression mechanism is supported by SonarQube for Visual Studio.

Related pages

• External analyzer reports (NUnit, MSTest, xUnit)
• External analyzer reports (See "Notes on external .NET issues")
• .NET test coverage (Visual Studio Code Coverage, dotCover, OpenCover, Coverlet, Altcover, VSTest)
• Introduction

• Azure DevOps Extension

• Analysis of product projects vs. test projects
• Troubleshooting guide for .NET code coverage import
• Investigating the performance of .NET Analysis