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.


 


 

Comments (36)

  1. Drew Marsh says:

    Sounds great! I’m sure I speak for most people when I say I can’t wait to see it!

  2. Juan Felipe says:

    When’s the expected release date??

    The improvements sounds great!!

  3. Michael Murray says:

    Hi Juan – We’re shooting for late Q104, Sorry we can’t be more specific than that yet.

    Thanks – Michael

  4. Douglas McClean says:

    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?

  5. Sounds great! lots of useful new features and FINALLY the locking issue has been fixed 🙂

    Can’t wait!

  6. OS says:

    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.

  7. Oran says:

    Great stuff! Can’t wait to see it. Are there any rules to help with unit test coverage?

  8. Dave Donaldson says:

    This all sounds good and I look forward to it. However, will FxCop ever just be part of the VS.NET IDE? I know you can integrate FxCop now with the command line .exe, but it just seems logical to put this into the Visual Studio product itself.

  9. 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?

  10. "Ability to analyze just about anything running just about anywhere"

    Does this inlcude .NETCF assemblies?

  11. Inge says:

    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

  12. Ralf says:

    First of all great tool!

    Im project manager and i had many projects where we created some coding rules.

    Is it in planing to test for inline coding rules in source files like:

    if( … )

    { // { in next line!

    AND NOR

    if(( … ) { // {vnot in next line

    ?

    Would be a very nice enhancement if we dont only check for microsoft coding rules via reflection. We would to check for inline coding rules like spaces, brackets etc.

    cheers

    Ralf

  13. Jeffrey van Gogh says:

    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.

  14. 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.

  15. Dana Epp says:

    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

  16. Gunther says:

    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