Versions Compared

Key

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

...

Your .NET solution must be compiled if you want prior 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 themthe SonarQube analysis. The SonarQube analysis must be run in the same directory where the solution was compiled.

By default, the C# plugin triggers the execution of some external tools. To deactivate some of them, you can set the below properties:

Code Block
languagebash
# External tools to deactivate when the solution is not compiled
sonar.fxcop.mode=skip
sonar.gendarme.mode=skip
sonar.gallio.mode=skip
sonar.ndeps.mode=skip

# Other external tools that you can deactivate
sonar.stylecop.mode=skip

Running an Analysis with the SonarQube Runner

  1. Compile your solution. SonarQube's primary goal is to analyze source code, so everything has been made to work seamlessly after the compilation of a solution. In other words, if you have a build process that moves the assemblies and package packages your application, it is definitely best to run SonarQube before (or in a separate process).

  2. Create a sonar-project.properties file and place it in the same folder as the solution file (.sln):

    Code Block
    titlesonar-project.properties
    languagebash
    sonar.projectKey=com.mycompany:myCSharpApplication
    sonar.projectVersion=1.0-SNAPSHOT
    sonar.projectName=My CSHARP Application
    
    # Info required for SonarQube
    sonar.sources=.   # Always set it this way even if this property is not used
    sonar.language=cs
    
    # To prevent any issues while analyzing multiple solutions containing projects with similar keys
    # Will be set by default to safe starting at version 2.2: http://jira.codehaus.org/browse/SONARDOTNT-339
    sonar.dotnet.key.generation.strategy=safe
     
    # This property is set because it is required by the SonarQube Runner.
    # But it is not taken into account because the location of the source
    # code is retrieved from the .sln and .csproj files.
    sonar.sources=.
    
    



  3. Run the following command from the directory containing the sonar-project.properties file (= the directory containing the solution):

    Code Block
    languagenone
    sonar-runner

...

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 file or any directoriesdirectory. ** means any directories and subdirectories:

...

Note
titleAvoid too much complex configuration of paths

If you start using absolute paths or placeholders in path patterns, this means that your configuration becomes more complex and you are likely to face issues sooner or later. Everything has been done to make sure you need to write as few configuration lines as possible.

 

Advanced Usage

Setting the .NET SDK to use

To set the default version of the .NET SDK to be used, 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 analysis configuration file.

...

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: the first string right after the equals sign on a project definition.
Known limitation: this property does not currently work while the "sonar.dotnet.key.generation.strategy" is set to "safe". See SONARDOTNT-10.

Code Block
languagebash
# To exclude "FooProject":

# ...
# Project("{E24C65DC-7377-472B-9ABA-BC803B73C61A}") = "FooProject", "FooProject", "{59BECB8B-A7E3-4823-9CE6-584D0D1755EE}"
# ...

sonar.skippedModules=FooProject

...

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

...

  • The solution has not been compiled prior to the SonarQube analysis
  • The solution has been compiled but the corresponding assemblies have been moved somewhere else (because of a specific build process) and SonarQube cannot find them
  • The solution has been compiled (and the assemblies have not been moved). But , then, the whole solution folder has been moved to another location (and therefore the debug PDB files no longer point to the original source locations)

...

Depending on when you run SonarQube in your continuous integration process, it is very important to properly set those properties. A proper configuration will allow SonarQube to automatically retrieve the assemblies and smoothly perform the analysis. It is highly recommend to that you run SonarQube right after the compilation phase.

IndeedFor example, if you run SonarQube after the packaging phase that moves for example all the assemblies into a single directory, you will face over-complicated configuration . You because you will have to tell SonarQube , for each project, where to find its the assembly for each project. To do so, set the sonar.dotnet.assemblies property. It is a path pattern that will be used to find the assembly of the analyzed project. Path The path pattern can be absolute or relative to the directory containing the ".csproj" file.

...

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

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

  1. Compiles the solution
  2. Runs a SonarQube analysis

...