JetBrains ReSharper is an awesome well-established tool now over two decades old! It offers hundreds of code inspections for C# and VB.NET. These inspections run in real-time within Visual Studio or the Rider IDE. In this post, we’ll explain how to integrate and report ReSharper code inspections within your CI/CD pipeline.
Export R# Code Inspections’ Issues to a json SARIF file
The free JetBrains tool, InspectCode.exe, allows you to run ReSharper code inspections on your C# solution or project (download it here). The detected issues are exported to a JSON file using the SARIF (Static Analysis Results Interchange Format) standard.
Previously, InspectCode.exe primarily exported results in XML format, but with JSON SARIF gaining prominence in the industry, it has become the preferred format for exporting ReSharper code inspections.
InspectCode.exe is very easy to use just open a command line window and type:
1 2 3 |
>cd "Path where inspectcode.exe has been unzipped" >inspectcode.exe "Absolute path to .sln or .csproj input file" -o="Absolute Path to .json or .sarif output file" |
The double quote character ” is necessary only if the path contains at least one space character.
Before scanning each source file, the tool compiles your solution, which may take a few minutes for larger projects. Once complete, you’ll obtain the resulting .json file.
Creating a Web Report With the R# Code Inspections
NDepend can import issues from a SARIF file during analysis.
You can download NDepend here and create a project using either VisualNDepend.exe or NDepend.Console.exe. On Linux or MacOS use ./net8/NDepend.Console.MultiOS.dll
(explanations here). The project can reference one or more solutions.
NDepend will automatically search for SARIF files in the directory $(SolutionDir)\.sarif
. If your ReSharper Code Inspections SARIF file is stored in this directory, no additional configuration is needed. This folder can also contain SARIF files with issues obtained from running Roslyn Analyzers, as explained here.
To obtain a report just run NDepend.Console.exe
with these arguments.
1 |
>NDepend.Console.exe "Absolute path to the NDepend Project .ndproj Extension" /ViewReport |
The file NDependReport.html
is outputted by default in the directory $(NdpProjDir)\NDependOut
.
Integrating into Your CI/CD Pipeline
Integrating into your CI/CD pipeline is simple: first, run InspectCode.exe to generate the SARIF file, and then execute NDepend.Console.exe.
1 2 |
inspectcode.exe "Absolute path to .sln or .csproj input file" -o="$(SlnDir)\.sarif\InspectCodeResult.json" NDepend.Console.exe "Absolute path to the NDepend Project .ndproj Extension" |
Exploring R# Code Inspections in the Web Report Generated
In NDependReport.html
, ReSharper code inspection issues are counted and reported in the same way as NDepend CQLinq rules issues and Roslyn Analyzer issues. You can generate the report against a baseline to see which R# Code Inspections are newly introduced, unresolved or resolved since the baseline.
In the Report Rules tab (see it live here), you can filter only R# Code Inspections:
Clicking on an inspection provides the explanation (if available), along with a URL and a list of related issues (see it live here):
Finally, clicking on an issue opens its source file (see it live here). The source file view includes issues generated by NDepend rules, Roslyn Analyzers, and also highlights code coverage data, if available at the time of NDepend analysis. Additionally, if the source file has been modified since the baseline, it is compared against its previous version.
There is also a view that lists all source files along with their issue count and code coverage ratio, as well as another view that displays all projects.
Turning Off R# Code Inspections
While NDepend rules address high-level issues such as poorly tested code, code quality regressions, and architectural entanglements, ReSharper Code Inspections and Roslyn Analyzers focus on fine-grained issues at instruction level. This sometimes leads to issues doublon.
An R# Code Inspection or a Roslyn Analyzer can be turned off in the file .editorConfig. Here you can find the identifier list for each inspection.
1 2 |
[*.cs] resharper_unused_parameter_global_highlighting=none |
Failing the Build Upon some R# Code Inspections Issues
NDepend.Console.exe returns a non-zero exit code when one or more Quality Gates fail. A Quality Gate is a code quality criterion that must be enforced and operate at a higher level than a rule, an analyzer, or an inspection. For example, a default NDepend Quality Gate is Treat Compiler Warnings as Error. It matches compiler warnings from Roslyn Analyzers and R# Code Inspections issues. Here is the Quality Gate C# LINQ source code:
1 2 3 4 5 6 7 8 9 |
// <QualityGate Name="Treat Compiler Warnings as Error" Unit="issues" /> failif count > 10 warnif count > 0 from issue in context.IssuesSet.AllIssues.Where( i => (i.Rule.Provider == RuleProvider.Roslyn && i.Rule.Id.StartsWithAny("CS","VB")) || (i.Rule.Provider == RuleProvider.Resharper && i.Rule.Category.EndsWith("CompilerWarnings"))) select new { issue, Explanation =issue.GetExplanation() } |
Conclusion
Many ReSharper Code Inspections and Roslyn Analyzers offer auto-fix options. Nevertheless, you may want to maintain control and stay informed about the amount of issues reported from your CI/CD pipeline. More importantly, it’s essential to track new issues introduced since the baseline, typically the last version of your code released to production. This approach maximizes your focus on the code that is actively being developed, helping you avoid the headache of dealing with thousands of issues in legacy code.