Какие более продвинутые правила необходимы для того, чтобы ваш код стал CLS-жалобой?

Question

Вот конкретный пример, который не является CLS-жалобой в соответствии с 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

Это интерфейс, который я реализую с помощью таких классов, как DbId32, DbId64, DbIdString и т. д. Это способ абстрагировать тип первичного ключа собственной базы данных в один общий тип .Net.

То, что я не отображаю, это метод фабрики, который создает правильный конкретный тип (например, новый DbId32 для типа SQL Server 'int') с учетом собственного типа базы данных.

Теперь допустим, что я использую этот интерфейс следующим образом:

Public MustOverride ReadOnly Property ID() As IDbId

VS теперь выводит это предупреждение:

  

Возвращаемый тип функции 'ID' не является жалобой CLS.

Я могу остановить эти предупреждения, добавив этот атрибут в мой интерфейс следующим образом:

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

Кажется, что ни одна из функций, определяемых этим интерфейсом, не нарушает задокументированных правил здесь . Так почему же VS отображает эти предупреждения?

Answer 1

Я думаю, это связано с модификатором ключевого слова MustOverride в вашем примере. Проверь это: Не совместимый с CLS член 'MustOverride' не разрешен в CLS-совместимом классе

Answer 2

Я запускаю FXCop , и это, кажется, всегда указывает на то, что чтобы сделать dll CLS-совместимым

Answer 3

Используйте .net рефлектор, чтобы взглянуть на сгенерированный код как с атрибутом, так и без него, и посмотреть, есть ли разница.

Если есть, и это не объясняет различий (т. е. если единственное различие - атрибут CLICompliant), то исправьте ваши вопросы с выводами, и я пойду еще раз ...:)