Currently, if you have the InternalsVisibleToAttribute applied to the assembly being analyzed, this rule will not fire on any constructors marked as internal (Friend in Visual Basic, public private in C++) as it cannot be sure that a field 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 constructors if every friend assembly is present in the analysis.

Although this rule states that there are no known scenarios where it is required to exclude (or suppress) this warning, there a couple of instances where this rule will incorrectly fire a false positive:

• If the class is created via late-bound Reflection methods such as Activator.CreateInstance.
• If the class is created automatically by the runtime or ASP.NET, for example, classes that implement IConfigurationSectionHandler or IHttpHandler.
• If the class is an implementation of a interface that represents a Windows Communication Foundation (WCF) service contract.
• If the class is passed as generic type parameter with a new() constraint. For example, the following will fire this rule:

[C#]

internal class Foo
{
   public Foo()
   {
   }
}

public class Bar<T> where T : new()
{
   public T Create()
   {
       return new T();
   }
}

  

  
[...]

Bar<Foo> bar = new Bar<Foo>();

bar.Create();

In these situations it is safe (and recommended) to simply suppress the warning.

This rule will also fire on types that are only ever instantiated by unused methods on that exist on the same type. This is by-design.

For example, the following type will fire this rule:

[C#]

internal class Book
{
    public static Book Create()
    {
        return new Book();
    }
}

[Visual Basic]

Friend Class Book

    Public Shared Function Create() As Book
        Return New Book()
    End Function

End Class