.NET Tools
Essential productivity kit for .NET and game developers
ReSharper Code Analysis Goes Beyond Visual Studio
One of ReSharper’s most notable features, Code Analysis, is now unleashed and ready to hunt for bad and dead code—without even opening Visual Studio. Dubbed as InspectCode, it is as simple as a command-line tool can be and requires a minimum of one parameter—your solution file. But as it runs it will apply all of ReSharper’s code inspections—that’s over 1,400 of them—to code in all languages supported by ReSharper!
Can’t wait to try it out? Find the latest ReSharper 8 EAP build, download and unzip the Command Line Tools package, and then run InspectCode [SolutionFile].
While the tool works its way through your code, let’s take a closer look at its features and use cases.
Output
Execution of InspectCode results in an XML file with code issues found within the specified scope (the whole solution or particular projects). The XML comprises two parts:
- The list of found issue types where each type has a description, severity level, and a link to the corresponding Code Inspection Wiki entry where available. Also, each issue has a category that can be used to group similar issues.
- The list of found issues where each issue has its type and place in a file. The issues are grouped by projects.
How the output should be processed is up to you. But here are a couple of recommended next steps: transform the output to an HTML report, or generate some messages on your continuous integration (CI) server based on number and types of detected issues.
Usage Scenarios
Now let’s see how we can use the tool and what exactly we can do with its output. It may be helpful to run it on your local machine, but only if you don’t have ReSharper, because with ReSharper you can get inspection results for a selected scope with a couple of clicks and, if necessary, export detected issues to a report file. A more promising case is to use InspectCode on a CI server where you can integrate it in the build script and add code inspection results to your build reports and messages.
The JetBrains Teamcity team, who is pioneering the use of this tool right now, has created the following visual presentation of the code issues detected by InspectCode:
To learn more, refer to the TeamCity documentation or download the latest version to try it out.
By the way, if you come up with more usage scenarios as you try out InspectCode, please share them with us.
Settings
If you have previously worked on the target solution with ReSharper, you may have already configured code inspections settings. If so, InspectCode will find your custom settings in .DotSettings files and apply them. If there are no settings files, then the default severity levels will be used for all inspections.
Besides custom severity levels for code inspections, InspectCode looks for the following settings in .DotSettings files:
- Whether solution-wide analysis is enabled (which may be overridden with the
/no-sweaparameter) - Naming rules
- Files, folders, and regions excluded from code analysis
If you want to configure InspectCode on a CI server, you can make all configurations locally with ReSharper, save the settings to the Solution Team-Shared layer, and then commit the resulting SolutonName.sln.DotSettings file in your VCS. InspectCode on the server will find and apply these settings.
As an alternative, you can configure InspectCode by specifying a shared .DotSettings file through the /profile (/p) parameter. In this case the specified settings layer will override settings in all other layers. (See this post to learn how to create and share a common settings file.)
Optional parameters
We have already mentioned two optional parameters: /profile (/p) and /no-swea. Among other optional parameters (which you can see by typing InspectCode /help) the following may come in handy:
/output (/o)– lets you set the output file. By default, the output file is saved in the %TEMP% directory./project– allows analyzing particular project(s) instead of the whole solution. After this parameter, you can type a project name or a wildcard that matches several projects within your solution./no-buildin-settings– can be used to ignore settings from the Solution Team-Shared layer (SolutonName.sln.DotSettings file)./caches-home– lets you specify a custom location for the data that InspectCode caches. By default, the %TEMP% directory is used, unless there are settings files, in which case the one specified there is used. This parameter can be helpful if you want to use a fast SSD disk for the cache or if you want to store all your build processing data in a single place.
So our command line could look like this:
InspectCode C:ProjectsReSharperresharper.sln /project=Documents /o="C:temp dataResults.xml" /no-swea
Q & A
That’s about all for the introduction of InspectCode. Now let us try and answer some questions you might ask:
- How are command line tools licensed?
The EAP version is a free 30-day trial. We are still working on the licensing policy and it will be announced soon. - Can I configure InspectCode without ReSharper?
Currently, configuration without the use of ReSharper is restricted to some basic settings like enabling solution-wide analysis, selecting projects to be analyzed, choosing the output file, and specifying cache location. - Does InspectCode consider the Visual Studio project setting ‘Treat warnings as errors’?
Yes. It will change the severity of issues corresponding to compiler warnings. - Will InspectCode analyze a solution that fails to build?
Yes. In this case you will see all compiler errors in the output in addition to ReSharper-specific issues. The only requirement for correct analysis is that all dependent libraries be referenced correctly.
If you have more questions or feedback about the Command Line Tools, we’ll be happy to hear from you.
Subscribe to a monthly digest curated from the .NET Tools blog:
