Question

We have a .NET web application with 172 projects on TFS 2008 that encompass all 3 tiers of the app and use Team Build for CI. We use VS2010 for development.

We would like to activate code analysis for all projects with Minimum Recommended Rule Set and enforce the check-in policy in TFS that code analysis should be run once before you check in. But we would like to have minimal impact to our developers in regard to their regular development check in process. Every time we enable code analysis in a project’s properties, a normal build time for that project shoots up by 100%.
We did an analysis of the code analysis issues and though there a lot of them even for this ruleset, it can be distributed among all developers who can fix them while doing their existing enhancements.

So basically we have two types of builds that we do:

1. Normal builds to check the propriety of the code which happens several times before we check-in the code.
2. Final build just before the check-in where we would also like to check for code analysis.

Hence we created another solution configuration called “DebugWithCA” which had its projects enabled for code analysis so that before the developer checks-in the code, he switches the configuration from Debug to DebugWithCA, builds and fixes the code analysis issues and then checks in. So that for normal builds, the developer stays in Debug solution configuration and does not have to bear the additional build time caused by Code Analysis.

But this too seems like an overhead as we have a lot of check-ins during the day (many developers) and switching solution configuration every time you check-in and switching it back becomes a pain.

Is there an easier way to accomplish our requirement?
While doing a build, is there a shortcut key that we can assign so that it builds with Code Analysis or builds with a specific solution configuration in VS2010?

Answer 1

I can think of two pragmatical approaches to circumvent your problem. Both suggestions take the code analysis out of the critical development path / time of the developer.

1. Have your DebugWithCA configuration activated in a Gated Check-in. The developer just checks-in the code and the build system makes sure code analysis is performed and the changes are only accepted when when no essential rules are violated.
2. Even more relaxed; just perform Rolling Builds based on the DebugWithCA configuration. Developers can pick-up rule violations off-line. Less preferred option, but also less intrusive.