Brain dump of some random things I’ve learned about code analysis policy settings — the settings that enforce code analysis prior to checking in source code.
- Team Foundation provides a way for the user to set a “lowest common denominator” code analysis policy at the Team Project level. Team Projects by default do not have code analysis policy enabled so if you do want this you will need to go into the settings and add the code analysis policy and set of rules you want to use.
- Once that is set, you can right click on a solution within solution explorer and migrate the code analysis policy settings to solutions. If you already have some rules set, this will result in the union of the two rule sets. I have found two ways to tune the system so that you get clean code analysis.
- To check what rules are set, go to your project properties. ASP.NET projects due to their unique nature have this in two places – the enabling is set via the project settings and the actual set of rules to be used in a secondary location is located in the code analysis configuration option in the website menu.
- What techniques to get code analysis running clean when various projects have different strictness levels? One is to think of the Team Project settings as a lowest common denominator, and then tighten up on a per solution basis. The other is to explicitly suppress violations on a per-visual studio project level by right clicking on the violation and suppressing. Finally at the end there is a bailout option to override the code analysis setting, but that should probably be considered more of a red flag than anything.
On a related note you can also set up a test list as part of checkin policy, the same place you would set up code analysis.