MSOCAF is a fine tool, provided by Microsoft to perform static code analysis on your code, before the code is deployed to an Office 365 or SharePoint site.
The issue with MSOCAF is that it is very slow.
To speed up resolving code issues, and also to prevent the same issues from re-occurring, it can be good to use the Code Analysis feature in Visual Studio 2012, to mimic the analysis performed by MSOCAF.
note: MSOCAF is updated regularly by Microsoft, and so it can be difficult to keep Code Analysis in sync.
However, if it is not obvious how to fix or suppress a message from MSOCAF, then using Code Analysis to reproduce the same message, can save a lot of time. This is because Code Analysis is much faster than MSOCAF, and works from directly within Visual Studio (no need to publish you SharePoint package!)
A few tips:
1. Issue with Code Analysis: non-public methods.
Some rules are only raised by Code Analysis in Visual Studio, if the method is *public*.
An example is CA2233 OperationsShouldNotOverflow
In order to reproduce a CA2233 that occurred in MSOCAF, I temporarily make the method public (if it is not already public).
I can then reproduce the error in Code Analysis.
I can then fix or suppress the message.
I then restore the visibility of the method.
Note: MSOCAF does not seem to have this problem.
2. Suppressing Messages using the Code Analysis results pane.
If you are happy that your code is correct, then you will want to suppress messages.
In order to fully suppress a message, it can be necessary to use the MessageId attribute, and other attributes.
Problem: It is not always obvious which attributes to use, and what text to place within the attribute.
Solution: instead of manually typing in the attribute to disable the message, instead:
a. run Code Analysis from within Visual Studio, to produce the message.
note: you may need to configure the Code Analysis for the project, to switch on the particular rule.
b. in the Code Analysis results pane. select the relevant error or warning.
There is an Actions link beside the rule.
Click on Actions. Select Suppress Message and then In Source.
This automatically adds the required attribute to the relevant method, that will suppress the message.
note: I prefer to suppress message for the method, and not the whole project.
When you suppress for the method, then the suppression attribute is co-located with the relevant code. I find this more maintainable.
3. Comment code, where MSOCAF has identified an issue.
Even when the issue has been fixed, a comment can help other developers to understand why code is the way it is.
4. If MSOCAF errors cannot be resolved, make comments and create a log
Sometimes MSOCAF errors cannot be fully resolved: the code cannot be changed, or else the code is OK but the error continues to be raised, and the error fails to be suppressed. This occurred for me (July 2013) with CA2233 and also with some MSOCAF custom errors (ULS logging via a 2nd class that MSOCAF did not detect, and no try..catch at top level for EventReceivers due to a method-scoped variable). In each case, the error was a false positive, and SuppressMessage did not work.
Solution:
a) make a comment in the code, to flag the MSOCAF error. This will save time in future, when the next MSOCAF report is generated.
b) create a human readable log (Excel or similar), to show relevant management / support staff. It should have columns like this:
note: step b) could be automated, if step a) is followed in a standard format, e.g.:
//MSOCAF override:ID: my justification here
References:
The issue with MSOCAF is that it is very slow.
To speed up resolving code issues, and also to prevent the same issues from re-occurring, it can be good to use the Code Analysis feature in Visual Studio 2012, to mimic the analysis performed by MSOCAF.
note: MSOCAF is updated regularly by Microsoft, and so it can be difficult to keep Code Analysis in sync.
However, if it is not obvious how to fix or suppress a message from MSOCAF, then using Code Analysis to reproduce the same message, can save a lot of time. This is because Code Analysis is much faster than MSOCAF, and works from directly within Visual Studio (no need to publish you SharePoint package!)
A few tips:
1. Issue with Code Analysis: non-public methods.
Some rules are only raised by Code Analysis in Visual Studio, if the method is *public*.
An example is CA2233 OperationsShouldNotOverflow
In order to reproduce a CA2233 that occurred in MSOCAF, I temporarily make the method public (if it is not already public).
I can then reproduce the error in Code Analysis.
I can then fix or suppress the message.
I then restore the visibility of the method.
Note: MSOCAF does not seem to have this problem.
2. Suppressing Messages using the Code Analysis results pane.
If you are happy that your code is correct, then you will want to suppress messages.
In order to fully suppress a message, it can be necessary to use the MessageId attribute, and other attributes.
Problem: It is not always obvious which attributes to use, and what text to place within the attribute.
Solution: instead of manually typing in the attribute to disable the message, instead:
a. run Code Analysis from within Visual Studio, to produce the message.
note: you may need to configure the Code Analysis for the project, to switch on the particular rule.
b. in the Code Analysis results pane. select the relevant error or warning.
There is an Actions link beside the rule.
Click on Actions. Select Suppress Message and then In Source.
This automatically adds the required attribute to the relevant method, that will suppress the message.
note: I prefer to suppress message for the method, and not the whole project.
When you suppress for the method, then the suppression attribute is co-located with the relevant code. I find this more maintainable.
3. Comment code, where MSOCAF has identified an issue.
Even when the issue has been fixed, a comment can help other developers to understand why code is the way it is.
4. If MSOCAF errors cannot be resolved, make comments and create a log
Sometimes MSOCAF errors cannot be fully resolved: the code cannot be changed, or else the code is OK but the error continues to be raised, and the error fails to be suppressed. This occurred for me (July 2013) with CA2233 and also with some MSOCAF custom errors (ULS logging via a 2nd class that MSOCAF did not detect, and no try..catch at top level for EventReceivers due to a method-scoped variable). In each case, the error was a false positive, and SuppressMessage did not work.
Solution:
a) make a comment in the code, to flag the MSOCAF error. This will save time in future, when the next MSOCAF report is generated.
b) create a human readable log (Excel or similar), to show relevant management / support staff. It should have columns like this:
| Category | Message | ID | Class | Method | line | Justification |
| Microsoft.Usage | OperationsShould NotOverflow |
CA2233 | DoubleExtensions | AlmostEqual | 214 | Method is checking for overflow bounds |
note: step b) could be automated, if step a) is followed in a standard format, e.g.:
//MSOCAF override:ID: my justification here
References:
Using Rule Sets to Group Code Analysis Rules:
How to suppress Code Analysis messages:
Comments
Post a Comment