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:
- detects if Unified Logging Service (ULS) logging is performed in every catch block.
- SPDiagnosticsService should be called at start and end of Timer Jobs, Event Receiver, Feature Receiver, and Web Services functions.
- 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.
Too bad that the rules used in MSOCAF still need some tweeking.