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 63 Next »

Table of Contents

Requirements

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 Practices

  • As you've already read in the requirements, your solution must be compiled before running a SonarQubeanalysis. However, please note that SonarQube'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 SonarQube 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 an Analysis with the 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 sonar-project.properties file that you can write to be able to run an analysis on your project:

    sonar-project.properties



  2. Run the following command from your Solution folder:

 

File location

Icon

The configuration file should be placed at the root of your Solution. This way, SonarQube will automatically discover the .sln file located in this folder.
If the Solution file is elsewhere, then you can 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 SonarQube Analysis with Maven

If you are familiar with Maven, you can also use the maven-dotnet-plugin in order 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

The POM file

Simplest "pom.xml" file for Maven

Above, a very simple pom.xml file that can be used instead of the sonar-project.properties of the SonarQube 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 SonarQubesuch 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

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:

Above pattern can be used to specify all the dll files of a lib folder located at the same level as the root folder of your visual studio solution.

As of version 1.4, $(SolutionDir) is not the only special expression that can be used in file patterns. Below the exhaustive list of supported expressions:

ExpressionDescription
$(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 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 sonar.dotnet.assemblies property with this pattern:

Tools such as Gendarme and FxCop will be executed once for each project of the solution. For each project, the expressions "AssemblyName" and "OutputType" will be evaluated in order to locate the project assembly.

Unit Tests and Code Coverage

There are two different ways to feed the SonarQube platform with information on unit tests execution and code coverage:

  • Letting the SonarQube platform drive the execution of the unit tests and the code coverage tool
  • Reusing reports that have been generated by external tools prior to the SonarQube analysis

Those two ways are handled by Gallio. So you first have to install it on the machine(s) running the SonarQube analysis. You also have to install the code coverage tool of your choice that will be driven by Gallio. Supported tools are dotCover, NCover, OpenCover and PartCover.

Configuring Gallio

Log in as a System administrator and go to Settings > Configuration > General Settings > .NET Gallio.

  • Set the path to the Gallio installation directory through the sonar.gallio.installDirectory property.
  • Define which tool to use to compute the code coverage through the sonar.gallio.coverage.tool property. Then, set the installation directory of this code coverage tool through the sonar.dotcover.installDirectory or sonar.opencover.installDirectory or sonar.partcover.installDirectory property. Note that there is not such a property for NCover as the installation path of NCover is automatically discovered by Gallio.

Letting the SonarQube platform drive the execution of the unit tests and the code coverage tool

This is the default mode.

The first and unique step is to tell SonarQube which assemblies are unit test assemblies. To do so, set the sonar.donet.visualstudio.testProjectPattern property.

Then, you just have to run a SonarQube analysis and you'll get data on unit tests and code coverage. Indeed, the paths to the compiled unit test assemblies are automatically retrieved from the Visual Studio "csproj" files. And the execution of unit tests and the driving of the coverage tool is automatically performed by Gallio.

Reusing existing reports

To activate this mode, add the following line to your project configuration file:

Then, you just need to provide SonarQube with the following reports: unit tests execution and code coverage.

Deactivating Unit Tests and Code Coverage

Add the following line to your project configuration file:

FAQ

My unit tests and integration tests are defined within the same assemblies, how can I run my unit tests only?

Define the sonar.gallio.filter property:

How can I exclude some specific assemblies and/or namespaces from code coverage computation?

Define the sonar.gallio.coverage.excludes property:

SonarQube cannot retrieve the compiled unit test assemblies

If for some reasons, compiled unit test assemblies are moved after the build (no longer available in directories defined in "csproj" files), you can tell SonarQube where to find them thanks to the sonar.dotnet.test.assemblies property.

How to define the Gallio runner type?

Set the sonar.gallio.runner property. As describe in the Gallio documentation, possible values are IsolatedAppDomain (PartCover default runner type), IsolatedProcess and Local.

Does not apply to NCover.

NCover Classic Edition License

As it is not possible to run tests for multiple test assemblies with the NCover Classic Edition license, set the sonar.gallio.safe.mode property to true. Gallio will then be launched once for each test assembly and then merge the generated XML reports.

How to set Gallio's timeout?

Set the sonar.gallio.timeoutMinutes property (default value is 30).

Integration Tests and Code Coverage

As the principles are very similar to the unit tests. please read the Unit Tests and Code Coverage before.

Letting the SonarQube platform drive the execution of the unit tests and the code coverage tool

To activate this mode, add the following line to your project configuration file:

The first and unique step is to tell SonarQube which assemblies are integration test assemblies. To do so, set the sonar.donet.visualstudio.itProjectPattern property.

Then, you just have to run a SonarQube analysis and you'll get data on integration tests and code coverage. Indeed, the paths to the compiled integration test assemblies are automatically retrieved from the Visual Studio "csproj" files. And the execution of integration tests and the driving of the coverage tool is automatically performed by Gallio.

Reusing existing reports

To activate this mode, add the following line to your project configuration file:

Then, you just need to provide SonarQube with the following reports: integration tests execution report and code coverage report.

Deactivating Integration Tests and Code Coverage

This is the default mode.

FAQ

See Unit Tests and Code Coverage > FAQ.

Corresponding integration test properties are:

  • sonar.gallio.it.filter
  • sonar.dotnet.it.assemblies
  • sonar.gallio.coverage.excludes (property shared with unit tests)
  • No labels