In previous posts about Code Metrics and Code Reviews, I explored some metrics and techniques that I felt should form part of any good software quality control process. One of the tools that I mentioned is FxCop. In this post I take a closer look at FxCop. I start by looking at how FxCop works and how you can fit it into your development process. I then consider the different rule sets to use and look at how you can utilise FxCop to guide your VS 2003/2005/2008 development efforts. I finish off the article by linking to articles that show you how to develop your own custom FxCop rules.
Introduction
FxCop analyses .NET assemblies for potential code compliance problems and forms part of static code analysis. With static code analysis the compiled code is checked for compliance to identify possible defects before executing the code. FxCop employs assembly analysis of generated assemblies using an introspection engine. Since the analysis is performed on the generated intermediate language (MSIL) code, FxCop is not dependent on any particular .NET implementation language. However, it is important to remember that assembly analysis cannot analyse certain aspects of the original source code, such as code comments, since these are not carried over in the compilation process. You may also run into a scenarios where there are differences between the FxCop violations in Debug and Release configurations due to the compiler optimisations being applied in Release mode.
FxCop ships with a large rule set analysing library design, globalization, interoperability, maintainability, mobility, naming, performance, portability, reliability, security and usage aspects of the assembly. The rule set can be extended to include new custom rules and existing rules can be switched off if necessary.
Process
FxCop will typically be used by the following people:- Developers use FxCop continuously during development, because it helps with familiarising themselves with the .NET coding best practices. As they progress they should find that they break fewer rules and can consequently rely on the tool less often. However, they should still continue to evaluate their code at predefined intervals in the SDLC. By actively using this tool, developers raise the standard of code going into code review sessions. I advocate for using the tool before every commit.
- Code reviewers use the tool to verify that developers are indeed complying with the best practices as defined in the rule set. They should also check that they agree with any "excluded" defects. Use of FxCop should rapidly improve both the speed and breadth of code review sessions by instantly highlighting the most obvious problems.
FxCop Backlogs
The following articles present some ideas on how to introduce FxCop into your SDLC:Rule sets
The rule sets provided with FxCop are quite extensive. Some rule sets (i.e Globalization/Mobility rule set) also includes rules that only apply to applications that target certain platforms/cultures/languages etc. Microsoft itself uses a sub-set of the complete FxCop rules to guide their own internal development efforts. From experience, I have created two rule sets to guide my own development efforts.Base Rule Set
The Base Rule Set is the rule set that I use for all new .NET development efforts. This rule set excludes the following rules:- Globalization Rules: CA1300: Specify MessageBoxOptions
- Globalization Rules: CA1301: Avoid duplicate accelerators
- Globalization Rules: CA1302: Do not hardcode locale specific strings
- Globalization Rules+: CA1303: Do not pass literals as localized parameters
- Naming Rules: CA1701: Resource string compound words should be cased correctly
- Naming Rules: CA1702: Compound words should be cased correctly
- Naming Rules: CA1703: Resource strings should be spelled correctly
- Naming Rules: CA1704: Identifiers should be spelled correctly
- Naming Rules: CA1726: Use preferred terms
- Usage Rules: CA2204+: Literals should be spelled correctly
- Usage Rules: CA2243: Attribute string literals should parse correctly
Minimum Rule Set
The Minimum Rule Set is the rule set that I use for all existing .NET development efforts. The idea is that these projects will most likely hit more rule violations on their existing code base and I therefore want to exclude some rules that add a lot of noise without providing IMO a lot of benefit. This rule set adds the following additional exclusions to those already excluded within the Base Rule Set:- Design Rules: CA1002: Do not expose generic lists
- Design Rules: CA1003: Use generic event handler instances
- Design Rules: CA1004: Generic method should provide type parameter
- Design Rules: CA1005: Avoid excessive parameters on generic types
- Design Rules: CA1007: Use generics where appropriate
- Design Rules: CA1010: Collections should implement generic interface
- Design Rules: CA1020: Use properties where appropriate
- Design Rules: CA1024: Avoid namespaces with few types
- Design Rules: CA1031: Do not catch general exception types
- Design Rules: CA1064: Exceptions should be public
- Globalization Rules: CA1304: Specify CultureInfo
- Globalization Rules: CA1305: Specify IFormatProvider
- Globalization Rules: CA1306: Set locale for data types
- Naming Rules: CA1705+: Long acronyms should be pascal-cased
- Naming Rules: CA1706+: Short acronyms should be uppercase
- Naming Rules: CA1707: Identifiers should not contain underscores
- Naming Rules: CA1713: Events should not have before or after prefix
- Naming Rules: CA1714: Flags enums should have plural names
- Naming Rules: CA1717: Only FlagsAttribute enums should have plural names
- Mobility Rules: CA1600: Do not use idle process priority
- Mobility Rules: CA1601: Do not use timers that prevent power state changes
- Performance Rules: CA1800: Do not cast unnecessary
- Performance Rules: CA1802: Use literals where appropriate
- Performance Rules: CA1805: Do not initialize unnecessary
- Performance Rules: CA1822: Mark members as static
- Usage Rules: CA2201: Do not raise reserved exception types
- Usage Rules: CA2205: Use managed equivalent of win32 api
- Usage Rules: CA2225: Operator overloads have named alternates
- Usage Rules: CA2242: Test for NaN correctly
Implementation
There are differences between using FxCop for Visual Studio 2003 and Visual Studio 2005/2008 development. For projects that have been upgraded from VS 2003 to VS 2005, read the following article for tips on how to migrate your existing VS 2003 FxCop exclusions file over to VS 2005 FxCop code exclusions.VS 2003
Obtain FxCop from here. Analyses can be performed from either using the FxCop GUI directly or from the FxCop command-line utility which allows you to integrate into a continuous integration process.VS 2005
VS 2005 adds static code analysis through integrating FxCop directly into the IDE. A developer can select to include static code analysis as part of the compilation process which will fire off FxCop and produce a list of errors/warnings in the Error list pane that prevents the code from compiling successfully. Code Analysis Policy for VS Team System can also be created that makes this code analysis process a compulsory step within the compilation process. This will prevent developers from skipping the static code analysis process.VS 2008
VS 2008 expands and improves on the code analysis provided in the VS 2005 IDE. Some of the improvements made are:- Ability to exclude generated code from code analysis
- Single MSBuild property to treat all violations as errors
- Inclusion of the FxCop standalone spelling rules
- Support for custom dictionaries to support the spelling rules
- Improvements to Code Analysis Policy
- Support for Anonymous Methods and Lamda Expressions
- Ability to Use Code Metrics as Check-in Policy
Continuous Integration
FxCop can easily be integrated into a continuous integration process by using the standalone FxCop command-line utility for VS 2003 or by using VS 2005/2008 Code Analysis. As already mentioned, development teams using Visual Studio Team System can include Code Analysis Policy to enforce the continuous use of FxCop in their development environments.Custom rule development
It is possible to write your own rules to integrate with FxCop running standalone or integrated into the VS IDE. Here are some articles on the topic:- How to write custom code analysis rules for VS 2005
- Custom rule sample
- How to debug a custom rule
- No rules in your FxCop assembly
Further reading
- Code Analysis and Code Metrics - The Visual Studio Code Analysis Team
- Design Guidelines for Class Library Developers - The FxCop rules are largely based on the guidelines contained in this document
- Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams
Nice article. By the way, you have included a sentence "You may also run into a scenarios where there are differences between the FxCop violations in Debug and Release configurations due to the compiler optimisations being applied in Release mode."
ReplyDeleteDo you know any solution to be applied for this, so that the number of violations in Debug and Release modes are the same.
Not that I'm aware of. Why do you need it though? We typically only run FxCop in Debug mode. We don't want the overhead of running it for Release mode and Release mode violations are typically a subset of the Debug mode violations.
ReplyDelete