интерфейс не реализован ошибка при подписании сборки C # - PullRequest
Новая
       22

интерфейс не реализован ошибка при подписании сборки C #

0 голосов
/ 05 января 2010

Я пытался подписать сборку и получил эту ошибку:

«Utils.Connection» не реализует элемент интерфейса «Interfaces.IConnection.BugFactory ()». «Utils.Connection.BugFactory ()» не может реализовать «Interfaces.IConnection.BugFactory ()», поскольку у него нет соответствующего возвращаемого типа «ThirdPartyLibrary.BugFactory».

Эта ошибка выглядит как грязная, грязная ложь! В Utils.Connection у меня есть этот метод: 

public new BugFactory BugFactory()

Я не думаю, что ключевое слово new является проблемой, потому что 1) удаление его не останавливает ошибку и 2) у меня та же ошибка с другим классом, который реализует IConnection, который делает не используйте ключевое слово new. Обновление: Если я использую override вместо new, я получаю эту ошибку:

'Utils.Connection.BugFactory ()': невозможно переопределить, поскольку 'ThirdPartyLibrary.ConnectionClass.BugFactory' не является функцией

Это потому, что ThirdPartyLibrary.ConnectionClass.BugFactory является собственностью.

Существует только один класс BugFactory, поэтому для интерфейса не требуется, чтобы тип возвращаемого значения BugFactory отличался от того, который возвращает метод. Даже если я явно помечаю свой метод как возвращающий ThirdPartyLibrary.BugFactory, я все равно получаю сообщение об ошибке, когда пытаюсь назвать строгое имя Utils DLL.

Может ли это быть результатом того, что ThirdPartyLibrary является старой библиотекой COM, которая не совместима с CLS? У меня нет контроля над этой библиотекой. Когда я не пытаюсь подписать сборку Utils, я не получаю ошибку интерфейса.

Мой большой вопрос: как я могу подписать эту сборку?

Редактировать: вот что IConnection имеет: 

using ThirdPartyLibrary; // The only using statement
namespace Interfaces
{
   public interface IConnection
   {
       ...
       BugFactory BugFactory();
   }
}

Ответы [ 4 ]

3 голосов
/ 05 января 2010

Я все еще подозреваю ключевое слово new для этой ошибки.

Вы говорите: «Я не думаю, что новое ключевое слово является проблемой, потому что 1) удаление его не останавливает ошибку», но вы должны иметь в виду, что если ваш метод скрывает базовый метод, компилятор добавит new, даже если вы не укажете это, если вы не указали для простоты override.

Все, что явно делает new, это предотвращение предупреждения компилятора (не ошибка).

Есть ли способ скрыть или переопределить вообще?

Что произойдет, если вы укажете virtual вместо new в этом методе. Это компилируется? Ошибка с «не найден подходящий метод для переопределения?»

[ Редактировать в ответ на ваш комментарий]

Я получаю эту ошибку: « 'Utils.Connection.BugFactory ()': не может переопределить, потому что 'ThirdPartyLibrary.ConnectionClass.BugFactory' это не функция. "Оригинал ThirdPartyLibrary.ConnectionClass.BugFactory это собственность.

Я подозреваю, что это может быть проблемой. Вы переопределяете свойство методом.

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

В отличие от этого, любой, у кого есть ссылка на суперкласс (тот, от которого вы наследуете), увидит старое свойство, а не ваш новый метод.

Можете ли вы дать еще немного кода суперкласса (или интерфейса) вместе с производным классом?

[ Редактировать в ответ на ваш комментарий]

Я пытаюсь изменить интерфейс на вместо этого BugFactory будет свойством метода

Проблема с новым заключается в том, что это похоже на магию, которая позволяет вам изменять типы аргументов и возвращаемые типы, но это действительно чистое зло.

Вместо того, чтобы изменять типы для всех потребителей кода, он делает это только для тех потребителей, которые представлены в качестве переопределенного нового типа. Это приводит вас в ужасное положение, когда два потребителя в одном экземпляре будут видеть разные подписи в зависимости от того, как они разыгрываются.

Посмотрите, сможете ли вы определить потребляющий код, который жалуется, и подумайте, нужно ли вносить изменения в ваш код для поддержки изменений типа. Кроме того, существует ли вероятность того, что вы пытаетесь сделать что-то, что "немного неприятно"?

1 голос
/ 05 января 2010

Похоже, вы просто ссылаетесь на библиотеку COM через диалоговое окно Add Reference. Вероятно, вам следует создать Первичную сборку взаимодействия для библиотеки COM, которую можно подписать. Одним из предостережений подписания сборки является то, что все сборки, на которые она ссылается, также должны быть подписаны.

Обычно вы используете программу SDK TlbImp:

TlbImp yourcomlibrary.tlb / primary /keyfile:yourkeyfile.snk /out:yourcomlibrary.dll

1 голос
/ 05 января 2010

Проблемы с пространством имен / версией?

ThirdPartyLibrary.BugFactory может быть другого типа, если у вас есть две разные версии сторонней сборки, на которые ссылаются как-то: одна во время компиляции и другая при подписи / проверке ..

0 голосов
/ 05 января 2010

Как выглядит ваш IConnection интерфейс? Кажется, у вашего ThirdPartyLibrary есть объект BugFactory, и у вас также есть объект BugFactory либо в вашем проекте, либо в другой ссылке. Вы пытались изменить интерфейс и конкретный тип на explicity, используя ThirdPartyLibrary.BugFactory в качестве типа возврата для этого метода?

...