Establishing a zero-warning policy with ReSharper’s solution-wide analysis

With the release of ReSharper 2016.2 we’ve announced a new feature called warnings in solution-wide analysis.

Basically, it means that after fixing all errors shown in the solution-wide analysis view, you will get a list of all warnings. When integrated both in your IDE and your TeamCity server, we think that this approach will appeal to developers striving for a high-quality code base, because it enables us to establish a zero-warning policy.

Let’s take a look at some random project as an example. We can see that it’s pretty much in a good condition; solution-wide analysis shows a green indicator:

ReSharper without warnings in solution-wide analysis

TeamCity build is also okay:

TeamCity build status

If you look more closely, the opened file contains warnings, but solution-wide analysis is still showing green. Apparently, they’re out-of-sync. Let’s fix this 🙂

In the following sections we will explain how your project and TeamCity needs to be configured to better reflect on errors and warnings reported by ReSharper. Most importantly, we will show how your development cycle can benefit from this setup. In conclusion, we will discuss a couple of related factors.

Configuring TeamCity

In order to configure TeamCity, you can either use a predefined build step or the ReSharper Command Line Tools package. If you use the package, make sure to set up a service message to import the XML report that will be produced.

A typical build step configuration would look like this:

TeamCity build step configuration

Whether you use the build step or the package, in both cases inspectcode.exe <SolutionFile>.sln  is called. For more information on available customization options, see inspectcode.exe /help .

Now, here’s the most important part of enforcing a zero-warning policy: if you want the build to fail when any errors or warnings exist, you need to configure a new build failure condition, preferably both for errors and warnings:

Alternatively, you can set the current number of warnings as a threshold to prevent it from growing, or set a percentage that must not be exceeded.

Next time you execute the build configuration, the summary page should include a Code Inspection tab, which lists all issues. In addition, the build can now be marked as failed due to violated inspections:

TeamCity Code Inspection tab

Configuring ReSharper

In ReSharper, establishing a zero-warning policy requires (1) turning on warnings in solution-wide analysis and (2) reviewing inspection severity settings.

Since ReSharper has a layered settings system, there are multiple ways to save the configuration of warnings in solution-wide analysis. For the enforcement of a zero-warning policy, we encourage you to use the solution team-shared layer for that setting.

Through the UI, you can enable warnings by toggling the new toolbar button in Errors/Warnings in Solution view, which will be saved to the this computer layer:

Enabling warnings via Errors/Warnings in Solution tool window

Alternatively, navigate to the Code Inspections Settings option page, and enable Include warnings. When saving, you can select the layer:

Enabling warnings via Options dialog

Keeping default inspection settings will do just fine for a start. However, for maximum benefit, there should be as many inspections as possible configured as errors/warnings in the solution team-shared layer as well. Especially inspections currently configured as suggestion are good candidates to change. Just sit together as a team and try to find your common ground.

Inspection severity options

If you want to change an inspection severity spontaneously, just do it from the editor:

Changing inspection severity from the editor

Whenever it is really necessary, you can use various styles of suppression comments to ignore an inspection.

Improved development cycle

Now that we’ve completed our configuration, the Errors/Warnings in Solution tool window has become a two-staged view for all severe issues in our solution. If there are any errors, then only errors will be shown. As soon as the last error is fixed, it will only contain warnings. In order to easily navigate through either errors or warnings, you can use ReSharper | Inspect | Next Error/Warning in Solution.

Warnings in ReSharper solution-wide analysis

By using parallel build configurations in TeamCity (the so-called snapshot dependencies), your team will also benefit from a fast feedback loop: right after implementing a feature and making the solution compilable, you can just push your changes and trigger TeamCity to report about test execution, code coverage and similar. Meanwhile, you are free to resolve all the remaining warnings using quick-fixes and refactorings provided by ReSharper.


Ignoring errors/warnings

As some may already have noticed, warnings cannot be ignored in the Errors/Warnings in Solution view. The initial problem with that was the discrepancy between the two-staged view and the existing feature to show ignored errors. Examining this feature a little further revealed that ignored errors are only persisted in caches. So let’s put this aside! We suggest three other solutions to false positive inspections:

  1. Suppress inspections in scope. Recommended when you only have a few false positives.
  2. Change severity of inspections. Useful with broken or unreliable inspections.
  3. Exclude items from analysis. Best used with generated code.

If none of the mentioned alternatives work for you, please leave us a comment explaining why you’re more into ignoring errors. We’d appreciate that! 🙂


As you may know, the existing set of inspections can be extended using plugins from the ReSharper gallery. Unfortunately, those extensions are currently only subject to solution-wide analysis inside the IDE. In fact, there is an issue filed to bring back support for extensions in the CLT. As soon as this issue is resolved, we highly recommend you to try extensions like ReSpeller, XmlDoc Inspections, CleanCode or Cyclomatic Complexity, and also include them into your zero-warning policy.

Comments below can no longer be edited.

17 Responses to Establishing a zero-warning policy with ReSharper’s solution-wide analysis

  1. Avatar

    Jimmy Rustler says:

    October 4, 2016

    Re-Sharper is good because i saves time and I like it

    • Avatar

      Derek Morrison says:

      October 5, 2016

      This is a precious, precious comment, Jimmy.

  2. Avatar

    Vasya says:

    October 4, 2016

    The problem is that there’s no way to ignore errors (well, “errors” in R# opinion). It would be great to have some way to do this. And of course, fix the bugs, for example,

    • Avatar

      Matthias Koch says:

      October 5, 2016

      Hi Vasya,

      unfortunately, the request hasn’t made it into priority yet. However, I just validated that the mentioned approach of excluding elements from analysis does work. Could you please validate that?

  3. Avatar

    frederic forjan says:

    October 4, 2016

    do you have any plan to have the command line tool avaiable as a task for TFS 2015 ?
    It would be awesome if you have an official extension for this 🙂

    • Avatar

      Matthias Koch says:

      October 5, 2016

      Hi Frederic,

      it would. However, we currently don’t have such plans. I can only advice you to use the mentioned command line solution until someone does that 🙂

    • Avatar

      Slava Trenogin says:

      October 16, 2016

      Hi federic!

      Mentioned nuget package has bundled MsBuild task to run inspect code and report errors/warnings as MsBuild ones, so you can fail build if necessary.

      I suppose, you can use that task in TFS.

  4. Avatar

    D.R. says:

    October 4, 2016

    Really like the new “warnings in solution-wide analysis” feature, thanks!

  5. Avatar

    HamRusTal says:

    October 5, 2016

    Is the SWEA supposed to show anything useful for native C++ code?
    I have a large enough solution of not-good-enough code but the pane tells me “No errors in solution”…

    • Avatar

      Igor Akhmetov says:

      October 7, 2016

      Ruslan, SWEA is not yet enabled for C++. You can however manually run ‘Find Code Issues’ on your solution to get a full report.

  6. Avatar

    Prumps Manjula says:

    October 6, 2016

    Hello. My English is not good, but is Reshaper good for registering COM DLL?

  7. Avatar

    Peter Morlion says:

    May 15, 2018

    It would be great if you could have Resharper fail the build if any errors are present. By this I mean the local build. It’s a longer feedback loop if we need to wait for the CI build to report this. Is it in any way possible to have the build fail when there are any Resharper errors?

    • Avatar

      Ron says:

      May 24, 2018

      I’m having the same issue. Without breaking the build, the errors aren’t totally useless, but close to it, for my use case.

      On a separate note, in the article, “Let’s take a look at some random project as an example” should be changed to replace “some random” with simply “a.” The project isn’t really random. The hackneyed and incorrect usage of “random” is generally unprofessional and should be avoided in this sort of forum.

  8. Avatar

    Le galles says:

    August 16, 2018

    I would like to apply a zero warning policy using TeamCity and R# 2018 but I want to ignore Hint and Suggestion: actually they are considered as warnings by TeamCity.
    The only workaround I can find is a XSLT transformation to get rid of all non-warnings and non-errors… which is a joke, isn’t it?

    • Avatar

      Le Galles says:

      August 16, 2018

      I found –severity=warning that does what I expect

  9. Avatar

    Miha says:

    March 12, 2019

    I want to check the result of analysis and fail the build if the number of warnings or errors is higher than 0, but I’m using Jenkins instead of TeamCity. It would be awesome if inspectcode.exe would return some different return code in that case. Or is there any alternative how could I achieve that? Some Jenkins plugin maybe?

    • Avatar

      Matthias Koch says:

      March 12, 2019

      I don’t know of any Jenkins plugin, but you could count the occurrences of <Issue TypeId= inside the XML report for instance.

      You can jump into discussion about return codes here:

Discover more