Detect code issues in a build using ReSharper and TeamCity

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 settings for code inspections. However, we can configure these to match our own/teams' criteria. This is done on the Code Inspection | Inspection Severity page of ReSharper options. We can change the severity of any inspection, for instance, that of using String.IsNullOrEmpty:

...and save the settings to the Solution Team-shared layer. 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

note

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.

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 running with the TeamCity Add-in for Visual Studio installed (if you do not, clicking on the link will prompt you with a dialog to download and install the add-in).

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 there 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 features, 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 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

With JetBrains tools, it is refreshingly simple to add code quality detection features to the build process and have a build fail if something that should not be in production code slips through.