Почему VB.Net не может найти метод расширения интерфейса?
=========================================================

У меня есть библиотека C #, которая имеет метод расширения, что-то вроде:

Расширение отлично работает, если вызывается из C #, но имеет проблему, если вызывается из внешнего приложения VB.Net:

Это прекрасно компилируется, но выдает исключение во время выполнения:

Public member 'ExtensionMethod' on type 'SomethingB' not found.

Если VB.Net изменяется, чтобы явно сделать тип интерфейсом, на котором он работает:

Зачем? Почему метод расширения работает с интерфейсом, а не с классом, который его реализует? У меня была бы та же самая проблема, если бы я использовал подкласс? Является ли реализация расширенных методов в VB.Net неполной?

Что я могу сделать в библиотеке C #, чтобы VB.Net работал без явного интерфейса?

С опцией Infer Off этот код ...

...такой же как...

поскольку`something` имеет тип`Object`, он не может найти метод расширения, так как он не определен для типа`Object`.

Теперь, если вы установите`Option Infer On`, вы получите те же результаты, что и в C #`var` ключевое слово. Типы будут автоматически выведены. Обратите внимание, что это может также сломать существующий код, но его можно включить для определенного файла, например,`Option Strict`.

Лучшей практикой было бы установить оба`Option Strict` а также`Option Infer` вкл.



Вы импортировали пространство имен, содержащее класс, который определяет пространство имен.

Например. вы не увидите ни одного из методов расширения LINQ to Objects без



Если этоthrowing an exception вместо того, чтобы выдавать ошибку во время компиляции, это говорит о том, что вы получили[Вариант Строгий](https://msdn.microsoft.com/en-us/library/zcd4xwzs.aspx) off ... Я не знаю, что происходит с методами расширения в этом случае, так как они обычно разрешаются вcompile time, но с опцией Option Strict вы связываетесь поздно.

Я предлагаю вам включить Option Strict, и все должно быть хорошо ...

(Вы & APOS; LLalso Мне нужно импортировать пространство имен, согласно ответу Ричарда, но я предположил, что вы это уже сделали. Вы увидитеcompile-time ошибка, если вы забудете сделать это после включения опции строго в любом случае.)



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

Методы расширения являются трюком компилятора, поэтому (в C #):

Преобразуется во время компиляции в:

Статический метод расширения, появляющийся как метод класса, является просто умом компилятора.

Проблема в том, что`Dim` в VB это не то же самое, что`var` в C #. Благодарю VB за позднее связывание, оно ближе к`dynamic`. 

Итак, с оригинальным примером в VB:

В отличие от C #, в VB выясняется тип`something` остается до времени выполнения, и хитрости компилятора, которая заставляет методы расширения работать, не происходит. Если тип явно объявлен, метод расширения может быть разрешен, но если применяется поздняя привязка, то методы расширения просто не могут работать.

Если они используют`Option Strict On` (как предлагает Джон), тогда они вынуждены всегда объявлять тип, происходит раннее связывание, и хитрость компилятора заставляет работать методы расширения. В любом случае, это лучшая практика, но, поскольку они этого не делали, это было бы болезненным изменением для них.

Мораль этой истории: не используйте методы расширения в своем API, если вы ожидаете, что кто-нибудь из VB окажется рядом с ним: -S