Currently if you have the InternalsVisibleToAttribute applied to the assembly being analyzed, this rule will not fire on any members marked as internal (Friend in Visual Basic, public private in C++) as it cannot be sure that a member is not being used by another friend assembly.

While it is not possible to work around this limitation in Visual Studio Code Analysis, the external standalone FxCop will fire on internal members if every friend assembly is present in the analysis.

This rule fires if there is calling code in a region that is in a preprocessor #if region such as the following case where, in a debug build, NotifyByEMail is thought not to be called.  Probably no way to fix it but definitely pay attention to it before you remove code regions detected by this rule since your code will compile fine and FXCop will tell you all is well until you flip the switch into release mode.

 

public void NotifyByEMail(string to) {

     ...

}

 

public void AnotherMethod() {

     ExecuteSomeCode();

#if !DEBUG

     NotifyByEMail(this.that@someplace.com);

#endif

}

I also had this rule fire when I had forgotten to put the public key word infront of the class definition
class DimAngle : IEquatable<DimAngle>
{
etc.....
public string ToString(string formatType, double scalar, int decimalPlaces) Rule was fired on this function "line 556"
{
.....
}
}
should have been
class public DimAngle : IEquatable<DimAngle>
{ .....
}
However the order in which the rule was reported fired wasnt listed top to botton but was picked up at some method quite a way down the class structure. Upon further invesigation I found the rule had fired on other public Methods and also private constants fileds that were used in several places in the code. I wasted much time untill I realised my mistake. So a note to others check that you have made the class public if you recieve this type of message when not expected.