ReSharper 2016.1 Help

Detect code issues in a build using ReSharper and TeamCity

Did you know that you can run ReSharper's
code inspections
for your builds on a
TeamCity
server?
In fact, we added support for this functionality in TeamCity a long time ago but it seems that the feature
is not widely known, especially 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 settings for code inspections.
However, we can configure these to match our own/teams' criteria. This is done on the
Code Inspection | Inspection Severity
options page.
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

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 box to download and install 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 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

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.