ReSharper 2019.2 Help

InspectCode Command-Line Tool

One of ReSharper’s most notable features, code inspection, is available even without opening Visual Studio. InspectCode, a free command line tool requires a minimum of one parameter — your solution file — to apply all of ReSharper’s inspections.

To run InspectCode:

  1. Download ReSharper Command Line Tools

  2. Unzip the command line tools package in any directory.
    Ensure that the downloaded .zip file is 'unblocked' before extracting: right-click the file, select Properties and click Unblock. Failure to do this will cause the .NET framework to load the application in partial trust, which means it won't load or run correctly.

  3. Build the target solution.

  4. Run the following command:

    InspectCode.exe YourSolution.sln -o=<PathToOutputFile>

Understanding output

When InspectCode finishes the analysis, it saves the results in an XML file specified in the command prompt -o=<PathToOutputFile>. This file includes all 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 corresponds to a specific inspection and has the following attributes:

    • Id — allows linking each issue to the corresponding inspection.

    • Category — can be used to group similar issues by categories.

    • SubCategory — if some issue types have the same SubCategory attribute, it means that the issues are same, but found in different languages or different scopes. You can use it for further grouping.

    • Description — describes the problem

    • Severity — shows the severity level of the inspection.

    • WikiUrl — a link to the corresponding Code Inspection Index entry where available.

    • Global — notifies a solution-wide code inspection.

  • The list of found issues grouped by projects, where each issue has the following attributes:

    • TypeId — allows linking each issue to the corresponding inspection (IssueType in the first part of the report)

    • File — path to the affected file, relative to the solution.

    • Offset — offset range in symbols from the beginning of the file to the beginning and the end of the problematic code.

    • Line - the line that contains problematic code.

    • Message — a short description of the problem.

    • Severity — this attribute only appears if the severity of the issue differs from the severity of the corresponding inspection. This is possible if some projects within the solution have the 'Treat warnings as errors' option enabled and others do not - in this case some issues would have the 'Error' severity, which differs from the original 'Warning' severity.

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. Also, with ReSharper you can open InspectCode reports.

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 has created the following visual presentation of the code issues detected by InspectCode:

Visual presentation of code issues in JetBrains TeamCity web interface

To learn more, refer to the TeamCity documentation or download the latest version of TeamCity to try it out.

Configuring InspectCode

Configuring InspectCode with ReSharper 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 will look for the following settings in .DotSettings files:

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 YourSolution.sln.DotSettings file in the solution directory to your VCS. InspectCode on the server will find and apply these settings.

As an alternative, you can specify a path to a shared .DotSettings file (which will override settings in other settings files, if any) through the --profile parameter.

Configuring InspectCode with command-line parameters

We have already mentioned some optional parameters above. Here is the full list of command line parameters (which you can list by typing InspectCode.exe --help):

  • --output -o — lets you set the output file.

  • --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. For example, --project=*Billing.

  • --profile — by default, InspectCode will override its default settings with ReSharper settings from the 'Solution team-shared' layer SolutionName.DotSettings, if it exists. If necessary, you can use this parameter to specify another .DotSettings file, which will override all other settings. For example,

  • --format (-f) — by default, InspectCode writes its output in XML format. If necessary, you can specify other output formats [Html, Text] with this parameter. For example, -f=Text.

  • --jobs (-j) — by default, InspectCode uses heuristics to split its jobs and run them in parallel using as many threads/cores as available. If necessary, you can limit the number of threads, for example, -j=4.

  • --absolute-paths (-a) — by default, files in InspectCode's report are written with paths relative to the solution file. You can use this switch to have absolute paths in the report.

  • --swea and --no-swea — these parameters let you explicitly enable or disable solution-wide analysis. Otherwise, solution-wide analysis will be enabled or disabled based on the existing settings.

  • --severity (-s) — by default, InspectCode only reports issues with the severity level Suggestion and higher. This parameter lets you change the minimal reported severity level to [INFO, HINT, SUGGESTION, WARNING, ERROR]. For example, -s=WARNING.

  • --debug (-d) — use this option to add execution details of InspectCode to the output. If you have problems with InspectCode, these details will be helpful when contacting the support team.

  • --verbosity — by default, InspectCode only displays information messages in the log. Use this parameter to change the amount of information written to the log by the following levels (the order is from less to more detailed): [OFF, FATAL, ERROR, WARN, INFO, VERBOSE, TRACE].
    For example, if something goes wrong with InspectCode, you can contact ReSharper support and share a log file with all TRACE messages: --verbosity=TRACE 1> [path_to_log_file] 2>&1.

  • --disable-settings-layers -dsl — disables specified settings layers. Accepted values: GlobalAll, GlobalPerProduct, SolutionShared, SolutionPersonal

  • --no-buildin-settings — suppresses global, solution and project settings profile usage. Equivalent to using --disable-settings-layers: GlobalAll; GlobalPerProduct; SolutionShared; SolutionPersonal; ProjectShared; ProjectPersonal

  • --caches-home — lets you specify a custom location for the data that InspectCode caches. By default, the %LOCALAPPDATA% 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.

  • --properties — lets you override MSBuild properties. You can set each property separately (--properties:prop1=val1 --properties:prop2=val2), or use a semicolon to separate multiple properties --properties:prop1=val1;prop2=val2. The specified properties are applied to all analyzed projects. Currently, there is no direct way to set a property to a specific project only. The workaround is to create a custom property in this project and assign it to the desired property, then use the custom property in dupFinder parameters.

  • --dumpIssuesTypes -it — use this option to dump all existing code inspections to the output. This option should be used separately from actual analysis, that is without the solution argument.

  • --config-create and --config — these options allow you to pass the parameters described above with a configuration file. The first option will create a configuration file according to the current parameters; the second option is used to load the parameters from this file.

  • --toolset — explicitly specified MsBuild Toolset version (12.0, 14.0, 15.0). For example, --toolset=12.0.

  • --targets-for-references — Names of custom MSBuild targets that will be executed to get referenced assemblies of projects. The targets are defined either in the project file or in the .targets file. Multiple values are separated with the semicolon. For example, --targets-for-references="GetReferences".

  • --targets-for-items — Names of custom MSBuild targets that will be executed to get other items (for example, a Compile item) of projects. The targets are defined either in the project file or in the .targets file. Multiple values are separated with the semicolon. For example, --targets-for-items="GetCompileItems".

Here is an example of running InspectCode with a few command-line options:

InspectCode.exe --project=Documents -o="C:\temp\Results.xml" --no-swea -x=EtherealCode.ReSpeller "C:\Projects\ReSharper\resharper.sln"

Using ReSharper extensions with InspectCode

Some ReSharper extensions provide additional code inspections, which allow you to find even more potential problems in your code. Such extensions can be also used with InspectCode.

To run extra code inspections from a ReSharper extension with InspectCode

  1. Locate a NuGet package .nupkg that contains a ReSharper extension. You can either get it from ReSharper Gallery or create it for your own extension as described in ReSharper DevGuide.

  2. Copy this .nupkg file into the directory where the InspectCode.exe is located.

  3. Run InspectCode. It will detect all NuGet packages with ReSharper extensions in its directory and load them automatically.

Supported languages

InspectCode finds code issues in the following languages:

Language: C# Language: VB.NET Language: C++ Language: HTML Language: ASP.NET Language: Razor Language: JavaScript Language: TypeScript Language: CSS Language: XML Language: XAML Language: Resx Language: Build Scripts Language: Protobuf Language: JSON
Feature is available Feature is available Feature is available Feature is available Feature is available Feature is available Feature is available Feature is available Feature is available Feature is available Feature is available Feature is available Feature is available Feature is not available Feature is not available
Last modified: 18 November 2019