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 73 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 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 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:



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

Running a Analysis with Maven

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 sonar-project.properties 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:

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, Integration Tests and Code Coverage

See related documentation page.

 

  • No labels