Full documentation for SonarQube has moved to a new location: http://docs.sonarqube.org/display/SONAR

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Requirements

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

...

Code Block
languagenone
sonar.fxcop.mode=skip
sonar.gendarme.mode=skip
sonar.gallio.mode=skip
sonar.ndeps.mode=skip

Best Practices

  • As you've already read in the requirements, your solution must be compiled before running a Sonar SonarQubeTM analysis. However, please note that SonarSonarQubeTM's primary goal is to analyse 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 build processes that move the compiled DLL or executables and package your application, it is definitely best to run Sonar SonarQubeTM before those steps (or in a separate process) otherwise you may run into troubles with over-complicated configuration of the C# plugins.
  • It is best to run the analysis from within the folder that contains the SLN file, in order to simplify the configuration of the C# plugins (e.g.: in such case, you do not need to tell where to find the SLN file).

Running a

...

SonarQubeTM Analysis with the Sonar 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 'sonar-project.properties' file that you can write to be able to run a Sonar an analysis on your project:

    Code Block
    titlesonar-project.properties
    languagehtml/xml
    # Project identification
    sonar.projectKey=com.mycompany:myCSharpApplication
    sonar.projectVersion=1.0-SNAPSHOT
    sonar.projectName=My C# Application
    
    # Info required for SonarSonarQube
    sonar.sources=.   # Always set it like that as this property is not used
    sonar.language=cs
    



  2. Run the following command from your Solution folder:

    Code Block
    languagenone
    sonar-runner

 

Tip
titleFile location

The Sonar configuration file should be placed at the root of your Solution. This way, Sonar SonarQubeTM will automatically discover the '.sln' file located in this folder.
If the SLN Solution file is elsewhere, then you can add set the 'sonar.dotnet.visualstudio.solution.file' property to specify its relative path, but we do recommend you to follow our best-practices.

Running a

...

SonarQubeTM Analysis with Maven

As it used to be the case for the .NET Plugins, Maven can be used to launch Sonar analyses on your C# code base.
If you are familiar with mavenMaven, you can also use the maven-dotnet-plugin in order to compile and package dotnet .Net projects. If you already use a CI tool such as Jenkins on Java Maven projects, you can use the the maven-dotnet-plugin to handle .Net projects the same way

The POM file

Simplest "pom.xml" file for Maven

Code Block
langxml
<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mycompany</groupId>
  <artifactId>myCSharpApplication</artifactId>
  <version>1.0-SNAPSHOT</version>
  <name>My C# Application</name>

  <properties>
	<sonar.language>cs</sonar.language>
  </properties>
  
  <build>
    <sourceDirectory>${basedir}</sourceDirectory>
  </build>
  
</project>

Above, a very simple pom.xml file that can be used instead of the sonar-project.properties of the Sonar Runner. If you want to use maven 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.

The settings file

You need to configure somewhere the location of the external tools used by Sonar SonarQubeTM such as FxCop, Gendarme or StyleCop. The C# plugins options pages describes the properties needed in the settings.xml. Below an xml fragment describing a maven profile you could add in your settings.xml file :

...

You can also use property keys used by the maven dotnet plugin. Feel free to take a look at the examples on the maven dotnet plugins.

Run the

...

analysis

Code Block
languagenone
mvn sonar:sonar

Paths and File Patterns

Each time you need to define the location of a file or a set of files, use '/' instead of '\' (even if that looks weird on a Windows box)
If you need to specify a path, this path may be absolute or relative. Relative paths may start from the location of the sln file or the csproj files, depending of the property specified. Relative paths may use "../" to climb in the folder hierarchy.
When several files need to be specified, for example for properties such as "sonar.dotnet.assemblies", " Ant style " wildcard patterns can be used. "*" means any file or any directory. "**" means any directory and subdirectory:

...

Above pattern will select any dll files prefixed by "Foo" anywhere in a project.
You can combine an absolute path prefix with wildcards:

...

This will select any dll files in any subfolder of the "lib" folder of the drive "T:".

If you need to reference assembly files outside your solution folder, you can use absolute paths or "../". For example:

Code Block
$(SolutionDir)/../lib/**.*dll

...

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

So if the solution you need to analyze use a "post compilation" msbuild/nant task that copies the generated assemblies somewhere into a "BUILD" directory, you can set the property "sonar.dotnet.assemblies" property with this pattern:

Code Block
$(SolutionDir)/BUILD/**/$(AssemblyName).$(OutputType)

...