To use FxCop and Gendarme, your .NET solution must be compiled. It is not necessary when using StyleCop.
FxCop needs to be installed. For Gendarme and StyleCop, versions embedded in the SonarQube plugins are used by default.
There are two different ways to feed the SonarQube platform with issues coming from these external tools:
Log in as a System administrator and go to Settings > General Settings > .NET FxCop or .NET Gendarme or C# StyleCop. For each tool, set the path to its installation directory through the
This is the default mode.
There is no additional configuration. Just run a SonarQube analysis and you'll get issues coming from these external tools.
To activate this mode, add the following lines to your analysis configuration file:
sonar.fxcop.mode=reuseReport sonar.gendarme.mode=reuseReport sonar.stylecop.mode=reuseReport
Then, you just need to provide SonarQube with the reports:
# Paths are relative to each project base directory sonar.fxcop.reports.path=reports/fxcop-report.xml sonar.gendarme.reports.path=reports/gendarme-report.xml sonar.stylecop.reports.path=reports/stylecop-report.xml
sonar.fxcop.mode=skip sonar.gendarme.mode=skip sonar.stylecop.mode=skip
sonar.gendarme.confidence property. Possible values are:
low / normal / high / total with + / -. Default value is:
sonar.fxcop.assemblyDependencyDirectories property to a comma-separated list of path patterns to locate the directories containing the dependency assemblies. Paths are relative to the folders containing the ".csproj" files.
With FxCop, it is the default behavior (
For all the tools, you can also use the Switch Off Violations plugin.
sonar.stylecop.analyzers.settings property to the file that holds additional settings for StyleCop. The path is relative to the folders containing the ".csproj" files.
This settings files will not be used to specify the active rules. Only settings such as "expected header contents", company names and so on will be used during the analysis.
sonar.<tool>.timeoutMinutes property (default value is 10).
This rule works at the class level. If you are working on a Windows form or ASP.NET project, you may have many partial classes. The code generated in the "designer" parts may contain many "visible fields" whereas the real code that matters does not contain any defects. In order to avoid these false positives, you have two options:
On an ASP.NET project you may configure the Switch Off violations plugin as follows: