JetBrains .NET Tools Blog

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-swea parameter)
• 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:\Projects\ReSharper\resharper.sln /project=Documents /o="C:\temp data\Results.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.

Since ReSharper introduced the layered structure for saving its options, we all face the choice of clicking Save or Save To whenever we change any settings. The good news is that the Save button will do the job for most users in most situations. The bad news is that, being tempted to go advanced and use the Save To button, you may not get what you expected without proper understanding of its design and purpose.

This post will hopefully help you click Save more confidently and opt for the Save To items only when you really need it.

Regardless of how you save ReSharper settings, you should always bear in mind that all settings you modify during one transaction (that is, between opening the Options dialog and clicking Save or Save To) can only be saved together. If you need these modifications to be saved in different layers, you have to repeat the transaction for each group of settings.

A rule of thumb when choosing between Save and Save To is the following:

• If you want to apply your modification but keep team-shared and/or custom layers (if any) intact, click Save.
• When you want to save modified settings to the Solution team-shared layer or a custom layer, click Save To and select the target layer.

If you want to know exactly how it works and why, please read on.

Default Settings

When you start with a fresh and clean installation of ReSharper, you can go to ReSharper > Manage Options and see that the following settings layers are prepared for you:

There are three predefined layers in order they apply (from bottom to top):

• This computer
• Solution team-shared
• Solution personal

You can even see the file names and locations of these layers. But do they really exist? If you haven’t made any changes to ReSharper options, the answer is NO: just look for settings files in your solution folder or your local application data folder, none of them are there. What you are seeing right now in the Settings Layers dialog are rather predefined destinations for settings layers that will be created as soon as you change any settings.

However, default settings must be defined somewhere…  and they are in fact defined in ReSharper system files; moreover, they are never changed. The trick here is that instead of changing default values of settings, ReSharper overrides them in different settings layers and then applies the value of the uppermost layer in the layer stack for each setting. Default settings are not shown in the Settings Layers dialog, and that’s why you may think that default settings are stored in This computer layer.

Let’s visualize the default state of ReSharper options. Imagine that ReSharper has only three settings (I wish it did) that define different colors. The default value is ‘blue’ for all three settings and the ‘Resulting settings’ are what we see in the ReSharper’s Options dialog:

As long as any settings layers are empty or do not exist, they are transparent for ReSharper and it applies values from the default settings.

Why Three?

At this point you may ask, why are there three predefined settings layers, no less and no more?  Well, they are there for your convenience. Here are some scenarios in which you may need these layers:

• Need to have your settings applied globally in your computer – they will be saved it in This computer layer
• Work on a team-shared solution and need to use the same code styles, templates, SSR patterns, etc. within this solution – then save these settings in the Solution team-shared layer; according to the concept, setting values defined in this layer will override not only the default settings, but also your personal global settings defined in This computer layer.
• Need to have some settings applied only in a particular solution independent of your team – then save them in the Solution personal layer; this layer will override all other settings, including those defined in the Solution team-shared layer.
• Want to have a set of settings for some solutions, another set for others, etc. – this is a less common case and it is not covered by the predefined setting layers; however it is possible with custom layers: see Per Project Settings or How to have different naming styles for my test project
• Want to have the same settings for all solutions within your team – this is also possible with custom layers: see ReSharper 6.1 Settings: DropBox and Company-wide

The chart below explains the use of all three layers. Suppose that you changed all default settings globally and had ‘green’ instead of ‘blue’ values. Then, after a discussion with your team, you decided that you would have settings A and C ‘yellow’ within your team-shared solution. Finally, you realized that you felt more comfortable with the ‘green’ value for setting A, and you changed it in the Solution personal layer, so as to have the desired value applied without changing the team-shared layer:

As you can see, all this is possible using the three predefined setting layers.

How Does Save Work?

The Save button is called ’smart save’ within the ReSharper development team, and for a good reason. Not only does it decide where to save the value of a modified setting, but it also compares the new value with the default value and those in other layers. Here are some common scenarios of how the Save button works:

First, let’s see what happens if the setting is not defined in any layers. Here everything is pretty simple: If the new value differs from the default value – the value is saved in This computer layer; if the value matches the default, it is cleared from This computer layer.

The setting that you change  may be already defined in the Solution team-shared layer and/or in custom layers. If this is the case, the  new value is saved in This computer layer (to be applied in other solutions) and in the Solution personal layer ( which always overrides all other layers for the current solution). If the new value is the same as the resulting value on the top of the  stack of layers, it is simply cleared from the Solution personal layer.

What About Save To?

Unlike Save, the Save To button is pretty straightforward: it saves all changes in the current transaction to the selected setting layer. Let’s see why, and when you need to use this button.

There are several approaches to have ReSharper settings saved in the Solution team-shared or any custom layers, including copying settings from other layers and import of settings. But the simplest way is to change the desired settings in the ReSharper’s Options dialog, and then use the Save To button to save the modifications to the particular layer.

The only catch with Save To is that after saving a setting to a particular layer, it may NOT be applied if the same setting is defined with another value in other layers above in the stack of layers. The illustration below shows how we tried to change setting C to ‘red’ by using Save To and why the resulting setting failed to be changed.

Afterword

This article touches upon the basics of ReSharper’s layered concept of saving settings. Custom layers, which were not discussed here, follow this concept and bring ultimate flexibility to the way you can store and share ReSharper settings. If you want to learn more, please follow the ReSharper settings tag here at JetBrains .NET Tools Blog.