InspectCode Command-Line Tool

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.

note

Another way to get the list of code issues is to run code inspection in ReSharper and then export inspection results to a file. However this can give a slightly different results because:

• InspectCode does not include issues that have Hint severity level, but ReSharper does.

• InspectCode can use different configuration that might disable some inspections or change their severity levels. For example, if you use the --profile parameter to load custom settings.

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. If necessary, you can 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:

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

Configure InspectCode using DotSettings

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:

• Whether the solution-wide analysis is enabled (this can be configured either in .DotSettings files or with the --swea/ --no-swea parameters)

• Naming rules (this can only be configured with .DotSettings files)

• Files, folders, and file masks excluded from code analysis. You can also specify which files should be included using the --include/--exclude command-line parameters.

• Files, file masks, and regions with generated code, where the code analysis is partly disabled (this can only be configured with .DotSettings files)

• A place where the code analysis engine should store caches. You can specify it on the Environment | General page of ReSharper options or with the --caches-home command-line parameter.

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.

Use EditorConfig to configure code inspections

If you use EditorConfig to maintain code styles for your project, you can also configure code inspections from .editorconfig files.

As EditorConfig convention suggests, InspectCode will apply inspection settings defined in files named .editorconfig in the directory of the current file and in all its parent directories until it reaches the root filepath or finds an EditorConfig file with root=true. File masks specified in .editorconfig files, for example *Test.cs are also taken into account.

Inspection settings in .editorconfig files are configured similarly to other properties — by adding the corresponding lines:

[inspection_editorconfig_property]=[error | warning | suggestion | hint | none]

For example, you can change the severity level of the Possible 'System.NullReferenceException' inspection to Error with the following line:

resharper_possible_null_reference_exception_highlighting=error

tip

Inspection settings from .editorconfig files have higher priority than the settings configured on the Code Inspection | Inspection Severity page of InspectCode options (Alt+R, O).

You can find EditorConfig property for each inspection on pages in the Code inspection index section as well as on the Index of EditorConfig properties page. — just use the browser search to find the property for the desired inspection.

Configure 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):

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"

MSBuild. Possible problems and solutions

When InspectCode receives the target solution file, it needs to create a list of files to be inspected and initialize a number of properties, such as language version. InspectCode uses MSBuild to get this information from project files.

In most cases, InspectCode automatically finds the proper MSBuild executable for the target solution. But there might be problems that prevent auto-detection, such as when the version of the solution runtime does not match the version of the installed .NET SDK.

If InspectCode yields an error such as The current .NET SDK does not support targeting .NET Core 3.0. or The SDK 'Microsoft.NET.Sdk' specified could not be found., you need to specify the correct SDK or runtime using additional parameters. If you work with .NET, MSBuild is already installed on your machine, and often more than one installation exists, so you have to provide one that fits the target solution.

In most cases you will have to add just one parameter — --toolset or --dotnetcore. In complicated cases, for example, many different installations on the machine or when using a custom version of MSBuild, you may need other parameters: --toolset-path, --mono, --targets-for-references, --targets-for-items.

When you specify --dotnetcore or --dotnetcoresdk, InspectCode will try to use MSBuild from .NET Core SDK and ignore others. For example, if you have several installations of MSBuild v 16.0 on your machine and specify a path to .NET Core installation with --dotnetcore, InspectCode will use .NET Core MSBuild from the specified installation. When --dotnetcore is not specified, InspectCode will look into the solution directory, try to find global.json, and use the SDK version specified there. If nothing is found, the latest available SDK version will be used.

Project references. Possible problems and solutions

MSBuild is also used by InspectCode to resolve symbols from referenced projects and assemblies. There are two project properties that allow using different references depending on the environment: Platform and Configuration. If the environment where you run InspectCode differs from the environment where the project was last built, you can receive errors such as: Can't resolve reference XXX: Reference wasn't resolved by MsBuild or Could not resolve this reference. Could not locate the assembly "XXX".

If you get such an error, check the output to see whether there is a mismatch in build configurations. For example

.....
JetBrains Inspect Code 2020.1
Running in 64-bit mode, .NET runtime 4.0.30319.42000 under Microsoft Windows NT 10.0.17134.0
Custom settings layer is mounted. Used file XXXXX.DotSettings
Using toolset version 15.0 from "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin"
Configuration: Debug, Platform: x86
.....

In the above, you can see that the platform specified in the project file is x86, but the tool is running in a 64-bit mode. To fix this, specify the target platform and the configuration explicitly with the --properties parameter: --properties:Platform=x64;Configuration=Debug.

Use 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.

Supported languages

InspectCode finds code issues in the following languages: