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:

TeamCity build is also okay:

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. 

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:

Configuring ReSharper

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:

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

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. 

If you want to change an inspection severity spontaneously, just do it 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. 

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. 

Remarks

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:

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? 

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. 

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?