If you are just starting to use code analysis, you may be mistaken for symptoms. You see: f 1. The code analysis takes considerable time, and 2. During the code analysis the project creates
You can combine these two symptoms and conclude that code analysis forces you to rebuild your project. That would be a false assumption. Try the following:
- Make sure your projects are set up so that they don’t perform code analysis during assembly
- Recover your decision. Note how long it takes
- Create (not rebuild ) your solution, but this time pay attention to how long it takes
You will find that your solution is actually “building”, but since the projects are updated, compilers and other tools do not start.
So, it is true that code analysis first builds your solution, but it will be a build similar to # 3 above - nothing has changed, so the tools will not work. Only the code analysis tool (FxCop) will be launched. It takes longer than you might expect, but it's worth it.
In our environment, I created a "Local" solution and a project configuration copied from "Debugging". This configuration is basically the same as Debugging, but does not perform code analysis. This is what our developers use day after day. When the code is validated in TFS, it starts the continuous integration (CI) assembly in the "local" configuration, again, without code analysis.
On the other hand, the nightly build starts the Debug configuration, so it starts the code analysis. I find that we do not need the results of the code analysis for each assembly, but it is damn necessary once a day.
OBTW, code analysis is not new. If you look at this MSDN page that you linked to, you will find the version of 2010 in the Other Versions drop-down list. In fact, the code analysis feature was available as a Visual Studio add-in called "FxCop" before it became part of the product.