Thursday, March 1, 2012

MSOCAF false positives

I've been struggling with MSOCAF lately. It turns out that validation of the developed SharePoint solution is quite hard. And it turns out that the validation of the tools still has a lot of errors.
A couple of examples:
  • The tool implements SPDispose check. It is a fantastic tool to detect the right disposal of SharePoint objects, but sometimes it can't determine the context right. These errors are taged with 'could be false positive'
  • MSOCAF implements a couple custom FxCop rules, but these are the quite problematic ones. For example, it detects the usage of deprecated classes and members. It uses the list found on MSDN with deprecated members. But in the notes added, there is the source of errors:
    Note: Types and methods in the Microsoft.SharePoint.Portal namespace are not included in these lists because, with a few exceptions, the entire namespace has been made obsolete.
    What it means, the Microsoft.SharePoint.Portal namespace? If you look at the MSDN documentation, you see that all classes directly in this namespace are deprecated or internal. But the FxCop rule is implemented as (thank you Reflector):
    if (fullName.Equals(str3) || fullName.Contains("Microsoft.SharePoint.Portal"))
    . And here disaster strikes. My code use a new SP2010 class AverageRatingFieldControl. But as this one is in the Microsoft.SharePoint.Portal.WebControls namespace, it is marked as a deprecated class (see FxCop rule). And now I need time to justify the use of a deprecated method.
  • MSOCAF does like logging to ULS, no problem with that. It checks a couple of rules:
    1. detects if Unified Logging Service (ULS) logging is performed in every catch block.
    2. SPDiagnosticsService should be called at start and end of Timer Jobs, Event Receiver, Feature Receiver, and Web Services functions.
    3. Any errors happening in the Feature Receiver upon activation and deactivation should be logged to the ULS and the exception must be reported back to SharePoint.
    But as with logging in code, developers like to create a generic method for that, where my custom application categories will be set. But no, MSOCAF keeps complaining that your ULS is not filled with data. And again, inspecting the FxCop rules turns out that it expect you to directly call the SPDiagnosticsService.Local.WriteTrace method. As it checks the IL generated code, sometimes this won't check right in debug mode. Also, using properties as parameters in the WriteTrace function will mess with the callstack, and probably influence the outcome of the FxCop rule negatively.

Too bad that the rules used in MSOCAF still need some tweeking.