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 as illustrated in the following diagram.
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.
I strongly recommend using FxCop together with a refactoring tool like ReSharper which makes fixing the rule violations a lot easier and less error prone.
FxCop Backlogs
The following articles present some ideas on how to introduce FxCop into your SDLC:
- FxCop and the big-bad-backlog
- FxCop backlogs: Some rules for rule activation
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
+ Not available in VS 2008
This rule set can be downloaded and is available as either a FxCop Standalone Template or VS 2005/2008 Project File Exclusions file.
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
+ Not available in VS 2008
The rule set can also be downloaded and is available either as a FxCop Standalone Template or VS 2005/VS 2008 Project File Exclusions file.
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:
Also be sure to check out the custom FxCop rule to support the multi-targeting feature of VS 2008.
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 documented here. 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:
Further reading