New users as well as users of the recent versions of the C# plugins should consult this page.
- "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 prior to the SonarQube analysis. The SonarQube analysis must be run in the same directory where the solution was compiled.
sonar.fxcop.mode=skip sonar.gendarme.mode=skip sonar.gallio.mode=skip sonar.ndeps.mode=skip sonar.stylecop.mode=skip
Running an Analysis with the SonarQube Runner
- 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 packages your application, it is definitely best to run SonarQube before (or in a separate process).
Create a sonar-project.properties file and place it in the same folder as the solution file (.sln):
Code Block title sonar-project.properties language bash
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=.
Run the following command from the directory containing the sonar-project.properties file (= the directory containing the solution):
Code Block language none
Always use "/" instead of "\" (even if it looks weird on a Windows box).
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.
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.
The same parametrization is available for the Silverlight Framework:
By default, generated code is excluded from the analysis (Reference.cs or *.designer.cs files):
sonar.dotnet.excludeGeneratedCode is set to
On some specific components, you can also prevent issues from being 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.
# Relative path from the analysis configuration file to the folder containing the solution sonar.dotnet.visualstudio.solution.file=my_solution_directory/solution_file.sln
The configuration defined to build the solution will be used to locate the assemblies during the SonarQube analysis. Two properties are taken into account:
# If, for each project, the assembly is moved to a "bin/package" directory inside the project directory sonar.dotnet.assemblies=bin/package/$(AssemblyName).$(OutputType) # If all the assemblies are copied into a "package" directory located in the solution directory sonar.dotnet.assemblies=$(SolutionDir)/package/$(AssemblyName).$(OutputType)
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).
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:
set platform=[enter] sonar-runner
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