JetBrains .NET Tools Blog

Did you know that you can run ReSharper Code Inspections on the server using TeamCity? In fact, we added support for this functionality in TeamCity just over a year ago but it seems that the feature is not widely known, specially by ReSharper users.

The setup itself is extremely simple, and we’re going to walk through it, and additionally add some more goodies in the mix.

Activating .NET Inspections in TeamCity

Adding ReSharper inspections to the build process is merely adding the Build Step named Inspections (.NET). The only parameter required is the Visual Studio Solution file

If we do not specify a Custom settings profile path, TeamCity takes the default ReSharper settings for code inspections. However, we can configure these to match our own/teams criteria. This is done via Options | Inspection Severity. We can change a specific setting severity, for instance, that of using String.IsNullOrEmpty

and save the settings to the Team Shared file. This then saves the settings in a file named {Solution}.sln.DotSettings which is normally checked in to source control so that it automatically applies to other team members when the solution is opened in Visual Studio. We can use this same settings file to indicate custom inspection settings for TeamCity

Analyzing results

When the build step runs, TeamCity generates a navigable report for us to analyze inspection results

We can navigate through the inspections for the entire project or a specific namespace. Inspections are grouped by Category, Issue Type and the corresponding files on the right pane. We can even navigate to the actual file by clicking on the line number. For this though, we need to have Visual Studio and the TeamCity plugin for Visual Studio installed (if you do not, clicking on the link will prompt you with a dialog box to download and install the plugin).

The checkbox Inspections with new problems only is used to highlight only new issues since the last build run. The numbers in bracket (+1 –1) are the variance since the last run.

Taking action based on inspection severity

One of the main benefits of adding inspections on the server-side is to put some level of code quality in place, whereby we can have the build process take action based on a series of conditions. For instance, we might like to have a build fail if too many warnings or errors are detected. 

Under Build Failure Conditions in the Project Configuration window, we can add a new Build failure condition:

We select Fail build on metric change and then indicate whether we want a build to fail based on warnings or errors. In our case we’re going to select errors and have it fail if it is more than one.

It should be apparent that if we want inspections to have an impact on the status of our build, that is, have a build fail, we can only do so based on Warnings or Errors. Therefore, Hints and Suggestions cannot be used. As such, when configuring inspections severity in ReSharper, we should take this into account.

If we now run our build again, it should fail as the number of errors are greater than one. Below is the output of the same input and inspections, but one run with the Build failure condition and the other without it.

Checking for copy/paste code

Although strictly speaking, this isn’t related to ReSharper, but since we’re talking about code quality in the build process, it makes sense to also mention that TeamCity can check for code duplication.

Much like before, activating code duplication is simply a matter of adding a new build step, namely Duplicates finder (.NET). We can indicate the folders to ignore, whether we want to take into account namespaces, type names, as well as a few other options.

The output is a nicely formatted navigable screen which allows us to go through the different files and see a side-by-side comparison of what TeamCity has detected as duplication (resized below for space limitations)

And as expected, we can also fail the build if we have too many code duplicates

Summary

It is refreshingly simple to add code quality detection features to the build process and have a build fail if something that shouldn’t be in production code slips through. The next step would be to provide Custom Patterns, which currently are not supported. If you feel this is a feature you’d like, let us know, and as always, any and all feedback is welcome.

As with every release, ReSharper comes with a number of inspections and fixes for diverse real-life development scenarios. This post illustrates both new inspections and quick-fixes as well as improvements to already existing analyses.

Inspection Smorgasbord

Here is a sampling of some new inspections that are making appearance in ReSharper 7.

• Since an is keyword implicitly performs a null check, ReSharper will now warn if you’re also performing the null check explicitly:

  

• Plenty of API calls support overloads which take string formatting specifications, but if you use string.Format() in those overloads explicitly, ReSharper will complain about the redundant call:

  

• When using OrderBy()-related LINQ methods, ReSharper will now complain if there is more than one such method in a call chain, and will offer to fix the situation by using a Then-prefixed method in the second call:

  

Also, ReSharper now provides usage inspections in response to Contract Annotations, which are explained in a separate post.

Quick-Fixes for Possible Multiple Enumerations

In ReSharper 6, we introduced an inspection to detect possible multiple enumerations of IEnumerable. In ReSharper 7, we have augmented this feature with quick-fixes to turn the enumeration into either a list or an array:

Both of the options replace the original declaration type with either an array or a list, calling the appropriate LINQ conversion method if necessary. Variable creation action also offers to use either var or an enumerable type:

Async/Await-Related Inspections

ReSharper is acutely aware of the async and await keywords and their proper use in .NET applications. Its support begins with basic recognition of missing or redundant keywords, together with appropriate fixes. For example, performing an await in a non-async method offers the following fixes:

ReSharper also takes care of various problematic use cases, such as having ref or out parameters in an async method:

Surround Templates as Context Actions

ReSharper has for a long time offered a separate command called Surround With Template (Ctrl+E,U) to surround blocks of code with different types of braces and preprocessing instructions. However, to make the feature even more convenient, ReSharper now offers these options as context actions when a block of code is selected. The top-level menu offers curly and round braces, with additional options offered in the submenu:

… and a lot more!

In addition to the examples above, ReSharper comes with a wealth of inspections and fixes for Windows Runtime applications as well as JavaScript. We have also previously demonstrated some inspections specific to various ReSharper features, such as INotifyPropertyChanged support and unit testing.

We hope you find these inspections useful in your day-to-day programming practice. Good luck!