What are the more advanced rules needed for your code to become CLS-complaint?

Question

Here is a specific example which is not CLS-complaint according to VS.NET 2005.

Public Interface IDbId

    Function GetNativeObject() As Object
    Function Equals(ByVal compObj As IDbId) As Boolean
    Function CompareTo(ByVal compObj As IDbId) As Integer
    Function ToString() As String

End Interface

This is an interface I implement with classes such as DbId32, DbId64, DbIdString, etc. It is a way to abstract the native database primary key type into one common .Net type.

What I'm not displaying is the factory method which instantiates the correct concrete type (ie new DbId32 for a SQL Server type 'int', for example) given a native database type.

Now let's say I go to use this interface like so:

Public MustOverride ReadOnly Property ID() As IDbId

VS now outputs this warning message:

Return type of function 'ID' is not CLS-complaint.

I can stop these warnings by adding this attribute to my interface like so:

<CLSCompliant(True)> _
  Public Interface IDbId
  ...

None of the functions this interface defines seem to break the rules documented here. So why is VS displaying these warnings?

Answer 1

I think it's due to the MustOverride keyword modifier in your example. Check this out: Non-CLS-compliant 'MustOverride' member is not allowed in a CLS-compliant class

Answer 2

I run FXCop and that seems to always point out what it takes to make a dll CLS-Compliant

Answer 3

Use .net reflector to take a look at the generated code both with and without the attribute, and see if there is any difference.

If there is, and it doesn't obviously explain the differences (i.e. if the only difference is the CLICompliant attribute), then amend your questions with the findings, and I'll have another go... :)