What's In The New Version Of FxCop [Michael Fanning]
As mentioned in previous blog and bulletin board posts, we’re in the final weeks of testing a new update to FxCop. This is a very significant update and I thought I’d post some information on what to expect in the release.
No more locks on assemblies or pdbs
FxCop uses a new, thread-safe, extremely performant metadata reader to crack assemblies. We no longer load assemblies via Reflection into the primary AppDomain and release all locks when FxCop is sent to the background. This means that you can now run VS side-by-side with FxCop, recompiling and observing the results on an analysis without having to exit and re-start FxCop. (On reactivating FxCop, btw, the tool will automatically determine whether it needs to reload a file that has changed).
Ability to resolve missing dependencies
We’ve resolved another current frustration with FxCop: the inability to load files due to missing assembly references. In the next release, FxCop will actively query for any missing assemblies that it requires. If you choose not to resolve a dependency, analysis will still occur (but will possibly be incomplete). FxCop will persists dependency directory locations to the project files, so that subsequent analysis don’t require further input. FxCopCmd.exe supports a new command-line argument as well to specify dependency directories.
Ability to analyze just about anything running just about anywhere
Because most metadata analysis occurs directly from the binary and not through framework api, it is now possible to analyze just about any version of an assembly, no matter what version of the framework FxCop is running on. E.g., you can analyze version 1.0 of your binaries while running on version 1.1, or vice versa. There will be some limitations analyzing binaries compiled against future versions of the framework, however, due to changes in resource stream formats and the addition of new security permissions that can’t be instantiated on 1.0 or 1.1.
Analysis is now multi-threaded. And can be cancelled (via UI or due to exceeding an exceptions threshold).
The new analysis engine is multi-threaded, permitting much greater CPU utilization on multi-proc systems. Analysis can be cancelled before completion, in which case the message set will consist of those violations that have occurred so far. There are also new project settings to disable rules or suspend analysis completely on exceeding an exception threshold. You can specify that rules should be disabled if they raise more than 2 exceptions, for example, and that analysis should stop completely if more than 20 occur.
New, powerful data flow analysis
FxCop ships with a new data flow analysis engine that enables a powerful set of new rules. We use this functionality to detect String.Concat calls that occur in a code loop, for example. This functionality comes at a performance cost, however, so it can be disabled within the UI if you’re most interested in speedy analysis with fewer code correctness violations.
Lots of UI improvements
The FxCop UI contains many subtle and a few not-so-subtle improvements. There is now a tracing window to capture tool output during analysis that might be useful in resolving issues. A new properties pane can be used to view metadata details for methods and types, or as an alternate to the message details dialog. FxCop can now show you the IL for method bodies, or generate a closure of the managed (and native) dependencies of an assembly. We have collapsed message level into a single, sortable column. We now support shift-click multi-column sorting. There are improved message copying options (you can specify your own XSL to apply before placing info on the clipboard). Most windows are ‘sticky’, size and location details are persisted between runs. We also have separate ‘sticky’ directory locations for adding rules, targets, or saving reports. There is improved support for jumping to method source locations in VS. And finally, a new ‘Rule Group’ option lets you create arbitrary groupings of FxCop rules (we ship with two built in, Breaking Change vs. Non-Breaking Change, and a grouping by Message Level so you could, eg, create a project that only runs rules generating Critical Errors).
This release reflects a lot of hard work and we look forward to getting it out the door. This will definitely occur in first quarter ’04.
And of course, new rules, rules topics and rules fixes (including spelling rule improvements).
This release will contain 20+ new rules in the areas of globalization, performance, design and usage as well as numerous rules fixes and refinements to eliminate false positives. FxCop can now pick up multiple custom dictionaries. You can also now specify an alternate language dictionary or locale, assuming one is installed on your machine. Users in the U.K., for example, can set spelling options to British English rather than U.S.
