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.

Comments below can no longer be edited.

15 Responses to ReSharper on the Server: Detecting Code Issues in the build

  1. Avatar

    Marcel says:

    October 10, 2012

    Having ReSharper code inspections on the build server is really an invaluable feature.

    Unfortunately, the current implementation still has a few flaws that makes the real world usage not as smooth as described (like easily excluding hints and suggestions from being reported). So looking forward to the next (minor) release that incorporates the feedback that got reported in your issue tracker.

  2. Avatar

    Joe White says:

    October 10, 2012

    What happens in the case of bugs in the ReSharper engine? Until recently, we had five “errors” show up in Solution-Wide Analysis due to RSRP-179197. (And EAP builds sometimes introduce their own spurious errors, like RSRP-331010.) On our local machines, we could ignore these errors in Solution-Wide Analysis, though they still showed up in the editor and the Marker Bar if we opened the affected file.

    As far as I know, when you say “ignore this error” for Solution-Wide Analysis, that setting is stored locally, not in the shared .DotSettings file. (If it was shared, we wouldn’t have to re-ignore the errors every time ReSharper decided that file needed re-scanning.)

    How would we ignore these sorts of ReSharper-bug errors if we were using TeamCity and running analysis on the server?

  3. Avatar

    Hadi Hariri says:

    October 10, 2012


    Can you please point out the issues on YouTrack?


  4. Avatar

    coox says:

    October 10, 2012

    Actually, ReSharper does not save ignored issues currently. A workaround could be is to completely exclude files with such erros from analysis. You may do that in ReSharper | Options | Code Inspections | Settings | Edit items to Skip.

  5. Avatar

    Robert Ellison says:

    October 10, 2012

    What would be really helpful is a command line engine that can be integrated with any build system. I’d love our company to switch to Team City, but it’s a big investment and not sure if and when it will happen. Before then Resharper is crippled by lack of integration with our existing build system – there is no way to enforce the rules at the build level.

  6. Avatar

    Immo Landwerth says:

    October 11, 2012

    That looks really cool.

    Are there any plans to make this feature available to non-TeamCity users as well? For example, we are using Team Foundation Server.

  7. Avatar

    John Saunders says:

    October 11, 2012

    It would be wonderful if you could create custom activities for TFS 2010/2012 builds that perform the same functions as the TeamCity equivalents.

  8. Avatar

    Marcel says:

    October 11, 2012

    The three issues that we are concerned about are:

    TW-21471 .NET Inspections: Add Options to the Build Step Page: Only Check For Errors
    TW-22788 Inspection “DataContext is unknown” reported even though inspection severity set to “Do not show”
    TW-22126 .NET Inspections runner should not execute solution wide analysis in case it was disabled via R#’s settings profile

    The first one basically prevents using the same settings file as the developer is using. The second one makes TC show errors that we explicitly de-activated from reporting, ie. the error count could never go down to zero. For the third there is a work-around, one just needs to take care to misspell the config parameter properly 😉

    At least the first issue we reported for a 7.0 EAP version – so it takes a bit of time to get things fixed. I simply would propose to nicely wrap up existing functionality before jumping to the next cool thing (to ensure that TeamCity remains the best build server infrastructure).

  9. Avatar

    Hadi Hariri says:

    October 12, 2012

    @Immo, @John,

    Currently it only runs under TeamCity.

  10. Avatar

    Hadi Hariri says:

    October 12, 2012


    We’re looking into these issues.


  11. Avatar

    joseph12 says:

    October 18, 2012

    It prevents using the same settings file as the developer is using.Thanks for sharing it.

  12. Avatar

    Julian says:

    January 22, 2013

    Any news on the issues reported by Marcel? I’m getting Hints and Suggestions reported in TeamCity. It should only be Warnings and Errors leaving the Hints/Suggestions for coding, otherwise it becomes impossible to set a build tolerance check on warnings as the next hint generated breaks the build.

  13. Avatar

    Calvin says:

    July 18, 2013

    This would be great if we could use it on TFS.

  14. Avatar

    Jura Gorohovsky says:

    July 18, 2013

    You can if you use ReSharper Command Line Tools

  15. Avatar

    Gamunu says:

    June 21, 2016

    Does re -sharper plugin with Team city has all most every rules same as with IDE (Licensed version)

Discover more