- "Project" means one project of a solution defined by a ".csproj" file.
- "Assembly" means a compiled project of a solution (dll or executable).
Your .NET solution must be compiled if you want to use the following plugins:
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 them:
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 your application, it is definitely best to run SonarQube before (or in a separate process).
It is highly recommended to run the analysis from within the folder containing the solution file.
If any of those best practises is not followed, you will likely face issues and over-complicated configuration of your analysis.
Running a Simple Analysis
SonarQube Runner (Recommended Way)
Create a sonar-project.propeties file and place it in the same folder as the solution file (.sln):
Run the following command from the solution directory:
If you are familiar with Maven, you can use the maven-dotnet-plugin to compile and package .NET solutions. If you also use a Continuous Integration server (such as Jenkins) on Java Maven projects, you can use the maven-dotnet-plugin to handle .NET projects the same way.
Create a pom.xml file and place it in the same folder as the solution file (.sln):
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.
Run the following command from your Solution folder:
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 analyzed 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 assembly. Can be "dll" or "exe".|
|$(RootNamespace)||Root namespace of the currently analyzed project.|
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 (sonar-project.properties ou pom.xml).
The same parametrization is available for the Silverlight Framework:
By default, the generated code is excluded from the analysis (Reference.cs or *.designer.cs files):
sonar.dotnet.excludeGeneratedCode is set to
To exclude projects, use theproperty. 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.
Detecting issues with external tools
Unit tests, integration tests and code coverage
See NDeps plugin.
Analysis succeeds but too few issues are found
Some tools like FxCop or Gendarme require assemblies. Having too few issues most often comes from the following reasons:
- 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 the whole solution folder has been moved to another location (and therefore the debug PDB files no longer point to the original source locations)
I cannot place the analysis configuration file in the directory containing my solution
Before following this workaround, make sure that you've got strong reasons not to put the analysis configuration file into the folder containing the solution. Note that this workaround may lead to further tricky configuration and issues.
SonarQube cannot retrieve the 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 assemblies during the analysis. Two properties are taken into account:
sonar.dotnet.buildConfigurationproperty (default value is
sonar.dotnet.buildPlatformproperty (default value is
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 assemblies. These paths are relative to the directories containing the "csproj" files.
SonarQube C# parser known limitations
- Pre-processing directives are not supported
- Parsing errors may occur with the '?' operator in specific circumstances (e.g. http://old.nabble.com/Problem-with-C--Squid-sensor-tt32091064.html#a32091064)
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 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:
- Compiles the solution
- 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.
Why do I get MSBuild error such as "error MSB4126: The specified solution configuration "Debug|HPD" is invalid"?
You are using a 64-bit windows OS. There is an environment variable "Platform=HPD" that makes msbuild fail. Try to run:
On Windows 7 I get "The Silverlight 3/4 SDK is not installed" error message
64-bit msbuild cannot be used with Silverlight. Check that you are not using a 64-bit msbuild by taking a look at
dotnet.3.5.sdk.directory properties. "Framework64" should not be present in the path.
The analysis fails with an OutOfMemory exception
The Java process performing the analysis might need more memory. Use the "-Xmx" option to specify the amount of memory that can be used. See the SonarQube Runner documentation for more details