Share via

What's In The New Version Of FxCop [Michael Fanning]

  • Article

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.

Comments

  • Anonymous
    January 19, 2004
    Sounds great! I'm sure I speak for most people when I say I can't wait to see it!
  • Anonymous
    January 19, 2004
    When's the expected release date??
    The improvements sounds great!!
  • Anonymous
    January 19, 2004
    Hi Juan - We're shooting for late Q104, Sorry we can't be more specific than that yet.

    Thanks - Michael
  • Anonymous
    January 19, 2004
    Excellent :).

    Are there plans to publicly expose the new data flow analysis engine to writers of custom rules, as with the Microsoft.Tools.FxCop.Sdk.IL namespace?
  • Anonymous
    January 19, 2004
    Sounds great! lots of useful new features and FINALLY the locking issue has been fixed :)

    Can't wait!
  • Anonymous
    January 20, 2004
    Lots of great improvements by the sound of it , now I'll have no excuse not to meet the standards ;)

    The no lock issue is big for me, awesome.
  • Anonymous
    January 20, 2004
    Great stuff! Can't wait to see it. Are there any rules to help with unit test coverage?
  • Anonymous
    January 22, 2004
    The comment has been removed
  • Anonymous
    January 22, 2004
    Very good point - I'd love to see this in the VS.NET UI as an optional part of the build process.
    Maybe with MSBuild this will be possible anyway?
  • Anonymous
    January 22, 2004
    "Ability to analyze just about anything running just about anywhere"

    Does this inlcude .NETCF assemblies?
  • Anonymous
    January 23, 2004
    Will we see a richer set of commandline options for FXCop? It would be good to be able to run its analysis as part of a Continuous Development Testing and Integration cycle - in conjunction with automated build/testing.

    -Inge
  • Anonymous
    January 26, 2004
    The comment has been removed
  • Anonymous
    January 26, 2004
    M. Scott Ford -> I just checked and we analyze CE binaries without any issues.

    Inge -> We added commandline options to specify reference directories, & platform location. All other FxCop options are settable trough the UI. The way to get these settings on the commandline is to either create a project without targets and pass that to the commandline or to set the project defaults.

    Ralf -> FxCop works of the binaries and does not parse sourcecode. FxCop can test things that are available in IL like method calls, locals etc.. but can not enforce sourcecode conventions.
  • Anonymous
    January 28, 2004
    Ok well, I could just say yeah sounds great like everyone else, but it doesn't seem like something I should yes-yes about. Bluntly, I don't use FxCop, it's too much trouble to use being an external application. This is definitely good news for the SDK developers and others, maybe Borland C#Builder users.
    I think it would be a reasonable target to aim for orcas to have it fully integrated into the VS.NET IDE, which is the preferred route by many accounts.
  • Anonymous
    February 10, 2004
    Thanks for a great tool guys. I finally had a chance to put it through my master sources today with awesome results in the catching and addressing of violations. If you care to read my review of the tool, you can check it out at http://silverstr.ufies.org/blog/archives/000518.html
  • Anonymous
    March 31, 2004
    Hello,
    thanks for providing latest and greatest FXCop 1.3, it's a great tool.
    The logical question after looking through the documentation would be:
    What is the Introspection Egnine and when will the SDK be availble and what rules can be written with that engine. I actually wnated some dataflow analysis....

    Cheers,
    Gunther