soloplan / resharper-clt-plugin

SonarQube plugin for ReSharper command line tools.

SonarQube ReSharper CLT Plugin

A SonarQube plugin for the ReSharper Command Line Tools.

Description

This plugin enables the analysis of C# and VisualBasic.NET source files contained in .NET projects using the output of the InspectCode JetBrains ReSharper Command Line Tool.

• Supports the most recent version of the JetBrains ReSharper Command Line Tools (at least version 2020.1.3)
• Compatible with SonarQube 7.9.x (LTS)
• Compatible with the SonarC# Plugin in version 7.5
• Compatible with the SonarVB Plugin (Visual Basic .NET) in version 5.2

Properties declared/used by this plugin

Property	Description
resharper.clt.solutionFile	The path to the Visual Studio solution file (.sln) parsed by the InspectCode command line tool.
resharper.clt.cs.reportPath	Used when analyzing C# projects. Defines the path to the XML report file generated by the InspectCode command line tool to be parsed by the plugin.
resharper.clt.vbnet.reportPath	Used when analyzing VisualBasic.NET projects. Defines the path to the XML report file generated by the InspectCode command line tool to be parsed by the plugin.
resharper.clt.xsd.validation	Enables XML Schema validation of the XML report file generated by the InspectCode command line tool. (not yet working)

How to use

A more in-depth guide on how to analyze projects that are built using MSBuild can be found in article Analyzing with SonarScanner for MSBuild of the official SonarQube documentation.

1. Install the ReSharper Command Line Tools plugin (see Installing a Plugin - SonarQube Documentation - Doc SonarQube for more details)
2. Enable at least one of the rules provided by the plugin in your quality profile (see Quality Profiles for more details)
3. Open a command prompt, preferably the Developer Command prompt for Visual Studio
4. Navigate to the root folder of the project/solution you want to build
5. Execute the following steps:
   1. Begin the SonarQube analysis and provide the values for the required properties
      SonarScanner.MSBuild.exe begin /k:"sonarqube_project_key" /n:"sonarqube_project_name" /d:sonar.login="%SONAR_LOGIN_TOKEN%" /d:resharper.clt.cs.reportPath="inspectcode_result.xml" /d:resharper.clt.solutionFile="%SOLUTION_FILE%"
   2. Build the project
      msbuild.exe "%SOLUTION_FILE"
   3. Run ReSharper Command Line Tool InspectCode.exe
inspectcode.exe /output="resharper.xml" "%SOLUTION_FILE%"
   4. End the SonarQube analysis, which will upload the issues to the server
      SonarScanner.MSBuild.exe end /d:sonar.login=%SONAR_LOGIN_TOKEN%

Configuration

It's possible to override the SonarSeverity for particular rules by providing a custom sonarqube_rule_overrides.xml. This can be either located in the base folder of the application or at a location specified with the environment variable: SONAR_PLUGIN_INSPECTCODE_OVERRIDEFILE=C:\config\my-sonar-inspectcode-rule-override.xml.

Updating the plugin for a new ReSharper version

The following command can be used to dump the rules into an XML file that is used by this plugin.

inspectcode.exe --dumpIssuesTypes --output="inspectcode_issue_definitions.xml" --no-buildin-settings 

After dumping the new ruleset, it is mandatory to check all the new rules and adjust the sonarqube_rule_overrides.xml accordingly, to account for any rules that should be categorized differently by default.

License

This project is licensed under the Apache License 2.0 - see the LICENSE file for details.

resharper-clt-plugin's Issues

Add an option to include all analysis

At the moment all the imported rules are filtered by this predicate

resharper-clt-plugin/src/main/java/com/soloplan/oss/sonarqube/plugin/resharper/clt/rules/CSharpRulesDefinition.java

Lines 56 to 63 in 0dd7568

	protected @Nullable Collection<Predicate<InspectCodeIssueDefinitionModel>> getIssueDefinitionFilterPredicates() {
	return Arrays.asList(
	ObjectPredicates.isNotNullPredicate(),
	InspectCodePredicates.hasValidIssueSeverity(),
	InspectCodePredicates.hasNonEmptyIssueDescription(),
	InspectCodePredicates.isCSharpIssueDefinition(),
	InspectCodePredicates.isVisualBasicIssueDefinition().negate(),
	InspectCodePredicates.isWebRelatedCategory().negate());

It'd be nice to have an option to disable this filter (except hasValidIssueSeverity and hasNonEmptyIssueDescription) or add two options, something like Rule ID regex and Category ID regex which will control this

resharper-clt-plugin/src/main/java/com/soloplan/oss/sonarqube/plugin/resharper/clt/predicates/InspectCodePredicates.java

Lines 111 to 113 in 0dd7568

	inspectCodeIssueDefinitionModel.getCategory() != null
	&& ("JsStrictModeErrors".equalsIgnoreCase(inspectCodeIssueDefinitionModel.getCategoryId())
	|| "JsStrictModeErrors".equalsIgnoreCase(inspectCodeIssueDefinitionModel.getCategory()));

and this

resharper-clt-plugin/src/main/java/com/soloplan/oss/sonarqube/plugin/resharper/clt/predicates/InspectCodePredicates.java

Line 38 in 0dd7568

Pattern.compile("^\\s*(?!AngularHtml\\.|Asp\\.|Cpp|Css|Es\\dFeature|Html\\.|VB|Web\\.|WebConfig\\.)\\S{3,}", Pattern.CASE_INSENSITIVE);

filter.

This may sound pretty insane, but the R# tools have more analytics than the SQ analyzers, plus R# is more robust at .csthml and .asp(x) parsing.

Solution filter in different folder as solution breaks relative paths to the source code files of issues

If InspectCode is executed with a solution filter, the generated xml has paths relative to the solution that the solution filter references, and not the solution filter.

However, this plugin assumes that the paths are relative to the folder of the solution file set as the resharper.clt.solutionFile parameter. See logic in https://github.com/Soloplan/resharper-clt-plugin/blob/137063b5c42562ca841c29384d340da9cc3d9e1e/src/main/java/com/soloplan/oss/sonarqube/plugin/resharper/clt/sensors/BaseSensor.java:

    // Build the absolute path to the solution file
    final File solutionFile = new File(sonarQubeProperties.userDir + File.separator + sonarQubeProperties.solutionFileName);
    final String inspectCodeRelativeBaseDir = solutionFile.getParent() + File.separator;

    // Iterate all issues found within the InspectCode report XML file matching the project name predicate
    for (SonarQubeIssueModel sonarQubeIssueModel : sonarQubeSensorXmlParserResults.parsedIssues) {
      ...
      // Construct an absolute path from the filesystem root to the source file where the issue occurred,
      // relative to the path where the solution file is located.
      final String absoluteFilePath = inspectCodeRelativeBaseDir + sonarQubeIssueModel.getFilePath();

Which means that you need to specify the actual solution as the resharper.clt.solutionFile, and the solution filter for InspectCode.

The xml that InspectCode generates does contain the analyzed solution relative to the userDir, so if this plugin would parse that path and use it to resolve the relative paths specified in the file, it would be less error prone.

And as far as I can tell, this is the only usage of the solutionFileName parameters, so maybe it could be removed (or made optional to override the path given in the xml if needed).

Report on exact position within the line

At the moment the plugin reports findings on the whole line. InspectCode provides "line" and an "offset range". For whatever reason it does not directly provide the position of the finding within that provided line (e.g. "position 11-18"), instead if gives the "offset" from the top of the file (in characters).
But in general the information would be there to report an issue at the exact location within a line. That would be very useful, esp. in more complex lines.

Fatal Error when using

Hello,

The following error occurs using this plugin when the MSBuild Scanner end step is run.

[1] - 08:54:17.478 ERROR: Error during SonarScanner execution [2] - java.nio.file.InvalidPathException: Illegal char <:> at index 29: S:\s\48518\PAP\xxx.git\S:\s\48518\PAP\xxx.git\Refactoring\yyy.zzz.DataBehaviour\yyy.zzz.DataBehaviour\Query\ProviderServices\entity\GetDetailsQuery.cs [3] - at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) [4] - at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) [5] - at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) [6] - at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) [7] - at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229) [8] - at java.base/java.io.File.toPath(File.java:2290) [9] - at org.sonar.api.scan.filesystem.PathResolver.relativePath(PathResolver.java:121) [10] - at org.sonar.api.batch.fs.internal.predicates.AbsolutePathPredicate.get(AbsolutePathPredicate.java:51) [11] - at org.sonar.api.batch.fs.internal.DefaultFileSystem.inputFiles(DefaultFileSystem.java:138) [12] - at org.sonar.api.batch.fs.internal.DefaultFileSystem.inputFile(DefaultFileSystem.java:108) [13] - at com.soloplan.oss.sonarqube.plugin.resharper.clt.sensors.BaseSensor.execute(BaseSensor.java:191) [14] - at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:48) [15] - at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:85) [16] - at org.sonar.scanner.sensor.ModuleSensorsExecutor.lambda$execute$1(ModuleSensorsExecutor.java:59) [17] - at org.sonar.scanner.sensor.ModuleSensorsExecutor.withModuleStrategy(ModuleSensorsExecutor.java:77) [18] - at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:59) [19] - at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:79) [20] - at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137) [21] - at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123) [22] - at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:384) [23] - at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:380) [24] - at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:377) [25] - at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:349) [26] - at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137) [27] - at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123) [28] - at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:136) [29] - at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137) [30] - at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123) [31] - at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72) [32] - at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:66) [33] - at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46) [34] - at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [35] - at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [36] - at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [37] - at java.base/java.lang.reflect.Method.invoke(Method.java:566) [38] - at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60) [39] - at com.sun.proxy.$Proxy0.execute(Unknown Source) [40] - at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:189) [41] - at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:138) [42] - at org.sonarsource.scanner.cli.Main.execute(Main.java:112) [43] - at org.sonarsource.scanner.cli.Main.execute(Main.java:75) [44] - at org.sonarsource.scanner.cli.Main.main(Main.java:61) [45] - The SonarScanner did not complete successfully [46] - 08:54:17.556 Post-processing failed. Exit code: 1
It appears to be concatenating a path and a path+filename as path+path+filename

Is there a solution or workaround?

Will

Can't analyze InspectCode report because the XML file to analyze defined by property resharper.clt.cs.reportPath does not exist: 'inspectcode_result.xml'.

Hi,
in azure pipeline report this "Can't analyze InspectCode report because the XML file to analyze defined by property resharper.clt.cs.reportPath does not exist: 'inspectcode_result.xml'."

Update to latest InspectCode (currently 2024.1)

With every release, JetBrains typically adds new rules. These new rules often target new C# language features. Please update the plugin so that these new rules become available in SonarQube.

Not sure if this is relevant for the plugin (I don't know if SonarQube parses the results or this plugin itself), but in the current documentation JetBrains notes

Starting from version 2024.1, the default output format of InspectCode is Static Analysis Results Interchange Format (SARIF). The XML format, which was the default in previous versions, will soon be deprecated. Results in the XML format are still available with the -f="xml" parameter.

Invalid rule key: CS0114

Some R# rules have ID with a comma, like

    <IssueType Id="CSharpWarnings::CS0108,CS0114" Category="Compiler Warnings" CategoryId="CompilerWarnings" Description="Keyword 'new' is required" Severity="WARNING" WikiUrl="https://www.jetbrains.com/resharperplatform/help?Keyword=CSharpWarnings_CS0108_CS0114" />

It seems like SonarQube doesn't allow commas in a rule ID and shows the error when you try to open an issue with such rule ID.