...ReSharper's code analysis is available without even opening Visual Studio...
One of ReSharper’s most notable features, Code Inspection, is available without even opening Visual Studio. InspectCode, a free command line tool is at your service. To perform code analysis, the tool 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! To try it out, download and unzip the Command Line Tools package, and then run
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:
...list of found issues where each type has its type and place in a file...
- 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
- 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 Wiki entry where available
- Global - notifies the 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 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 inspection. This is possible if some projects within a 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.
...use InspectCode on a CI server where you can integrate it in the build script...
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 team, who is pioneering the use of this tool right now, has created the following visual presentation of the code issues detected by InspectCode:
...InspectCode will find your custom settings in .DotSettings files...
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 the solution-wide analysis is enabled (this can be overridden with the /no-swea parameter)
- Naming rules (this can only be configured with .DoSettings files)
- Files, folders, and file masks excluded from code analysis (this can only be configured with .DoSettings files)
- Files, file masks, and regions with generated code, where the code analysis is partly disabled (this can only be configured with .DoSettings 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 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.)
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:
...analyzing particular project(s) instead of the whole solution...
- /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.
- /disable-settings-layers (/dsl) - disables specified settings layers.
Possible values: GlobalAll, GlobalPerProduct, SolutionShared, SolutionPersonal, ProjectShared, ProjectPersonal (note that the per-project settings are not available in the ReSharper GUI. To create a per-project settings file, you can save your settings as a solution-shared and then rename the settings file to the yourProject.csproj.DotSettings)
- /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 %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.
- /extensions (/x) – allows using ReSharper extensions that affect code analysis. To use an extension, specify its ID, which you can find by opening the extension package page in the ReSharper Gallery, and then the Package Statistics page. Multiple values are separated with the semicolon.
- /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). For instance, you can specify to treat warnings as errors: /properties:TreatWarningsAsErrors=true. 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 InspectCode parameters.
- /dumpIssuesTypes (/it) - use this option to add all existing issue types to the output. By default, only the types of found issues are added.
- /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.
So our command line could look like this: