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.
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:
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:
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:
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.
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:
- Suppress inspections in scope. Recommended when you only have a few false positives.
- Change severity of inspections. Useful with broken or unreliable inspections.
- 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.