Description / Features
The .NET ReSharper plugin supports using the free JetBrains ReSharper command line code inspection tool "InspectCode" as a source for .NET-based static analysis issues. ReSharper is an extremely popular commercial plugin to the Visual Studio IDE for .NET development and this plugin allows users to have a parallel experience in the IDE and in SonarQube when it comes to code analysis results.
What You Can Expect To See
Something like this in Visual Studio using ReSharper:
Will turn into this in SonarQube:
- The .Net Ecosystem plugins (C# Ecosystem and/or the VB.NET plugin), version 2.1 or greater
- The JetBrains ReSharper command line tools
- There are consistency issues in versions of the tools before 8.1, so it is recommended not using versions before 8.1
- Install the .NET and C# plugins following their installation instructions
- Install the sonar-dotnet-resharper-plugin from the Update Center or download them (link at top of this page) into the SONARQUBE_HOME/extensions/plugins directory
- Restart the SonarQube server
- Modify Your Project's Quality Profile (see below)
Modify Your Project’s Quality Profile
If you install the sonar-dotnet-resharper-plugin on a clean system where you have not modified the “Sonar way” Quality Profile, then all of the new ReSharper-based rules will be included and enabled immediately. However, if you have modified that profile or have your own custom profile(s), you will need to enable the ReSharper rules for that profile after installing the plugin. To do this, go into the SonarQube web UI, click the “Quality Profiles” link in the header bar, and choose the profile you wish to include ReSharper results.
In the filter boxes, choose “ReSharper” in the Repository field and “Any” from the Activation field and click "Search". I expect you’ll see a list of approx 650 rules, all disabled. In the upper right corner of the results list is a “Bulk Change” option. Choose “Activate all”. This will (immediately) activate all of the ReSharper rules for this profile.
Running an Analysis
Now, add the following properties to your sonar-project.properties file(s) based on which scenario you wish to follow.
Where the value of
sonar.resharper.reports.path is the path to the ReSharper results file relative to each project file, as an absolute path, or utilize any of the Path Patterns supported by the .Net ecosystem plugins. This has the current limitation (same as the FxCop and other sonar-dotnet plugins) of requiring the same relative path be used for all projects. As such, if your filesystem layout has project files at different depths relative to the results file, you should consider using an absolute path or one of the Path Patterns.
Where the value of sonar.resharper.dotSettings.path (optional) is the path to your ReSharper settings customization file (created by the ReSharper "Options" dialog in Visual Studio). Note: If the DotSettings file exists in the same folder as the .sln file and has the same base name as the solution (ex: MySolution.sln and MySolution.DotSettings), ReSharper will automattically use the file without having to provide it in this property. Providing a value here will override the name-based DotSettings file, which will then not be used.
And the value of sonar.reshaper.additionalArguments is added to the inspectcode command line. Values can be determined using the /help parameter to inspectcode and here: http://confluence.jetbrains.com/display/NETCOM/Introducing+InspectCode. The /properties argument can be used to provide MSBuild values and the undocumented /plugin can be used to include a local ReSharper plugin.
A Note About Rule Severity
ReSharper user a four-tier severity, while SonarQube uses a five-tier system. The plugin has mapped the ReSharper values like this in the initial rules profile loading:
|Do Not Show||Info|
While some of the ReSharper rules are marked as "Do Not Show" by default, the plugin maps them to "Info" so that you can modify their visibility via the Quality Profile. If you want them to not show, disable the rules in the Quality Profile. You can, of course, change any of these levels for any rule using the Quality Profile, and I fully expect most people will want to downgrade a lot of the ‘Critical’ rules to ‘Major’ and a lot of 'Info' to be turned off.
Adding Additional ReSharper Rules
SonarQube requires that the rule database be populated up front, at server start. ReSharper provides a list of possible violation types for their tool via the "/dumpIssuesTypes" argument, and the plugin will populate the SonarQube rule repository using these values (as of the plugin's build). However, as new versions come out, or you add your own ReSharper plugins to generate new IssueTypes, it’s possible that you will have violations in your code that the plugin did not know about when the server started, so cannot import into SonarQube appropriately. When the plugin comes across one of these, it will write a log statement (to the runner’s log) and generate a "Sonar.UnknownIssueType" violation with instructions on how to add the rule information to the 'ReSharper custom rules' property in the Settings UI. After adding that setting and restarting SonarQube, future analysis runs will support those IssueTypes.
Other File Types
While the ReSharper tools support the full .Net stack, including .xaml and other file types, the sonar-dotnet API does not currently support more than one language (C# or VB.net) for a given project. For .xaml and other files, the plugin attempts to report the violations against every file ReSharper reports, but they will show up in SonarQube without source code. Additionally, there are a handful of situations where they may end up attached to the project instead.
You can configure the plugin to only report violations against files that are supported by the dotnet plugins using the 'sonar.resharper.includeAllFiles' property.