ReSharper on the Server: Detecting Code Issues in the build

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



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.

13 thoughts on “ReSharper on the Server: Detecting Code Issues in the build

  1. Pingback: Dew Drop – October 10, 2012 (#1,419) | Alvin Ashcraft's Morning Dew

  2. Lior Tal

    I’ve been using it for quite some time. Although i don’t fail the build in case of errors, it helps to get a quick glimpse at overlooked issues with the code.

  3. John Adams

    The duplicate check is an elaborate band-aid for a problem that can be largely avoided by hiring developers with higher, more professional standards. If you have to check builds for duplicate code, you should be checking the developers, not the code.

  4. Pingback: Using ReSharper and TeamCity to Detect Code Issues in the Build | Eric S. Davis

  5. general1

    I had tried this months ago, and retried a few weeks ago. Our build times out, when using Resharper-on-teamcity checks, as we have a large code base. The teamcity properties seem to suggest that we could filter which files to check, but I have not yet been able to get this to work… Resharper seems to continue to check *everything* ?

    Another thought was, if we did not have a build timeout, to let resharper run indefinitely. We got an out of memory exception in this case 😦

    I did not report these issues yet. Does Teamcity support reporting to its issue-base, starting from build errors from build configurations ? That would be a nice feature ;-))

    So, if Resharper would have finished, and everything would have been properly reported to TeamCity, on the next build, would it still take so much time and memory, or would this reharper-on-teamcity work incremental ?

  6. generalone1

    Hey Hadidi,

    I re-enabled the build, indicating it got carte blanche, and ended successfully after 30 minutes.
    I did not think it would get that far – but it did. Congratulations to the TeamCity / Resharper team.
    I still feel it takes quite some time to investigate, and think this means it is not incremental.
    That would give it a great boost, if I’m thinking correctly.

    Thanks for your encouragement 😉


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s