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

insepctionsrunner

 

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

 

inspectionsresharper

 

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

 

settings

 

Analyzing results

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

 

image

 

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:

 

 

buildfailureinspections

 

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.

 

image

 

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.

 

buildoutput

 

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.

 

builddupeconfig

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)

image

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

buildfailuredupe

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.

This entry was posted in How-To's, ReSharper Tips&Tricks and tagged , , , . Bookmark the permalink.

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

  1. Marcel says:

    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. Joe White says:

    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. Hadi Hariri says:

    @Marcel,

    Can you please point out the issues on YouTrack?

    Thanks.

  4. coox says:

    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. Robert Ellison says:

    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. Immo Landwerth says:

    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. John Saunders says:

    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. Marcel says:

    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. Hadi Hariri says:

    @Immo, @John,

    Currently it only runs under TeamCity.

  10. Hadi Hariri says:

    @Marcel,

    We’re looking into these issues.

    Thanks.

  11. joseph12 says:

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

  12. Julian says:

    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. Calvin says:

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

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">