Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 84 Next »

Table of Contents


Your .NET solution must be compiled if you want to use the following plugins:

  • FxCop
  • Gendarme
  • Gallio
  • NDeps

If your solution is not compiled (or if you do not want to use some of the external tools for your analysis), you can deactivate the external tools by adding the following properties to your configuration file:

Best Practice

  • Note that SonarQube's primary goal is to analyze source code, so everything has been made to work seamlessly right after the compilation of a solution (and before any packaging made by a build process). In other words, if you have a build process that moves the compiled DLL or executables and package your application, it is definitely best to run SonarQube before (or in a separate process). Otherwise you may run into troubles with over-complicated configuration of the SonarQube C# Ecosystem.
  • It is best to run the analysis from within the folder that contains the Solution file to simplify the configuration of the SonarQube C# Ecosystem.

Running a Simple Analysis

SonarQube Runner (Recommended Way)

  1. Create a sonar-project.propeties file and place it in the same folder as the Solution file (.sln).
    Here is the simplest file that you can write to be able to run an analysis on your project:

  2. Run the following command from your Solution folder:

A sample project is available on GitHub that can be browsed or downloaded: /projects/languages/csharp/csharp-sonar-runner.


If you are familiar with Maven, you can also use the maven-dotnet-plugin to compile and package .Net projects. If you already use a CI tool such as Jenkins on Java Maven projects, you can use the maven-dotnet-plugin to handle .Net projects the same way.

  1. Create a pom.xml file and place it in the same folder as the Solution file (.sln).
    Here is the simplest file that you can write to be able to run an analysis on your project:

    If you want to use Maven to compile and run the tests of your Visual Studio solution, you also need to declare the maven-dotnet-plugin. Please take a look at the examples provided on the maven-dotnet-plugin site.

  2. Run the following command from your Solution folder:

Advanced Configuration

Setting the .Net SDK to use

To set the default version of the .Net SDK to use to analyze your source code, log in as a System administrator and go to Settings > Configuration > General Settings > .NET and set the sonar.dotnet.version property. Note that you can override this default value in your project configuration file ( ou pom.xml).

The same parametrization is available for the Silverlight framework: sonar.silverlight.version property.

Setting exclusions

By default, the generated code is excluded from the analysis (Reference.cs or *.designer.cs files): sonar.dotnet.excludeGeneratedCode is set to true.

To exclude projects, use the sonar.skippedModules property. It is a comma-separated list of project names. The names that must be used are the identifiers in the solution file: first string right after the equals sign on a project definition. 

To exclude files, see Project Administration#ExcludingFiles.

On some specific resources, you can also prevent issues to be raised against a set of coding rules: see the Switch Off Violations plugin.

Path Patterns

Always use "/" instead of "\" (even if it looks weird on a Windows box).

When noted as so, Ant style wildcard patterns can be used. * means any files or any directories. ** means any directories and subdirectories:


Special expressions can be used in path patterns:

$(SolutionDir)Root directory of the solution, this is the directory where the sln file is located.
$(ProjectName)Name of the currently analysed project of the solution.
$(AssemblyName)Name of the assembly generated by the currently analyzed solution. Works only for non-ASP projects.
$(AssemblyVersion)Version of the assembly generated by the currently analyzed solution.
$(OutputType)Type of the generated assembly. Can be "dll" or "exe".
$(RootNamespace)Root namespace of the currently analyzed project.

Detecting Issues with External Tools

See FxCop, Gendarme and StyleCop.

Unit Tests, Integration Tests and Code Coverage

See C# Unit Tests, Integration Tests and Code Coverage.

Architecture Check

See NDeps plugin.


I cannot define the SonarQube project configuration file in the directory containing my solution

Note that is a workaround that can lead to further tricky configuration. Make sure that you've got strong reasons not to put the SonarQube project configuration file into the folder containing the solution, before using this property.

SonarQube cannot retrieve the compiled assemblies

Note that it is strongly recommended to run a standard debug compilation build prior to any SonarQube analysis. Indeed, release mode is optimized and some tools such as Gendarme will not be able to find as many issues as they will with debug code.

The configuration defined to build the solution will be used to locate the compiled assemblies during the analysis. Two properties are taken into account:

  • sonar.dotnet.buildConfiguration property (default value is Debug)
  • sonar.dotnet.buildPlatform property (default value is Any CPU)

If the assemblies have been moved (that is not recommended at all prior to running a SonarQube analysis), you can tell SonarQube where to find them through the sonar.dotnet.assemblies property. It is a comma-separated list of path patterns to the compiled assemblies. These paths are relative to the directories containing the "csproj" files. For example, if the build process runs a msbuild/nant script just after the compilation that copies the generated assemblies to a "BUILD" directory, you can set this property to:

SonarQube C# parser known limitations

How can I integrate SonarQube in my existing TFS Build environment processes?

Most people want to add SonarQube as an additional step in existing processes, which usually brings a lot of troubles because those processes manipulate the generated artifacts (assemblies) - whereas the SonarQube C# plugins rely best on information found in the source files (mostly "csproj" files).

Generally speaking, it's best / easier to set up a separate "continuous inspection" process that just:

  1. Compiles the solution
  2. Runs a SonarQube analysis

in order to keep the SonarQube-related configuration as simple as possible.

You can read this thread to see how this has been achieved by C# plugin users.


  • No labels