This is the continuation of my last post regarding Code Analysis features in Visual Studio 2008 (Team System Editions, to be more clear). This time I will concentrate to the role Code Analysis plays in team integration.
Code Analysis Check-In Policy
If you are unfamiliar with Team System’s check-in policy, you should know that it is possible to constraint checking-in your pending changes. This can be done on a basis of:
- work items – requires that a work item (one or more) must be associated with the check-in,
- builds – the policy requires that a previous build was successful before any new changes can be checked in (so, the policy doesn’t check if the code should successfully compile before it can be checked-in, but rather a PREVIOUS BUILD should be successful),
- testing policy – requires that tests pass before a check-in can take place (you have an opportunity to choose appropriate metadata file (.vsmdi) and choose which tests should be triggered to constraint this),
- code analysis (requires that the code analysis check is triggered before the actual check-in).
For the last bullet, Code Analysis Policy Editor is shown in which you can choose several options:
At first, you can chose to enforce C/C++ code analysis and/or to enforce code analysis for managed code (i.e. C# or Visual Basic). Also, you can choose which rules must be obeyed when checking-in and how to treat them.
Code Metrics, as an option, is not (yet) available as a check-in policy, but there is a workaround for it. The point is, code metrics itself doesn’t have a check-in policy but its metrices are part of the CA warnings (inside Maintainability Rules). Therefore, if you mark the corresponding rules via Code Analysis Policy Editor, you will in fact, enable Code Metrics Check-in Policy, sort of say:
- CA1501 : AvoidExcessiveInheritance (Depth of Inheritance Metric)
- CA1502 : AvoidExcessiveComplexity (Complexity Metric)
- CA1506 : AvoidUnmaintainableCode (Maintainability Index)
- CA1506 : AvoidExcessiveClassCoupling (Class Coupling Metric)
Actually, all of this is not new in this version. What is new is that this code check-in policy can be integrated with your code analysis warnings inside a project. There are two problems regarding this integration found in past, which are solved in VS 2008:
- code analysis check-in policy (stored on the Team Foundation Server) didn’t easily migrate to the settings inside of each particular project,
- enabled code analysis warnings didn’t match the stored settings on the team system if they were changed afterwards.
Luckily, the CA developers solved these problems by adding two options found by Analyze menu item Code Analysis Settings for Solution:
- Replace with Check-in Policy – used to override your solution’s settings by the settings on the team system,
- Merge with Check-in Policy – used to integrate your solution’s settings into the global settings on the TFS.
Creating a Work Item from CA Warnings
Creating a task or a bug from code analysis warnings is easy as double-clicking on particular warning(s) inside Error List window and selecting this option:
What is really cool is that the task (or other work item definition) is filled with a title representing a CA warning name, and a description containing information about each CA warning selected (CA number, name, description, file, line, project where warning arises):
So much about it for now. Next time I will deal with the changes in particular rules – namely, new spelling rules and usage of custom dictionaries, multi-targeting rule, and the support for anonymous methods and lambda expressions (LINQ prerequisites).