Конфликт сборки при использовании Type.IsAssignableFrom (Type)

Question

Конфликт сборки при использовании Type.IsAssignableFrom (Type)

1

Я динамически загружаю DLL в Assembly. Моя проблема в том, что когда я пытаюсь использовать System.Reflection чтобы получить определенный тип из этой загруженной сборки, которую я хочу использовать для создания экземпляра этого типа. Тип, который я хочу, является интерфейсом.

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

Вот код:

IMyInterface _classInstance;

String path = Path.Combine(Application.StartupPath, "mydynamic.dll");
if (File.Exists(path))
{
   Byte[] ba = File.ReadAllBytes(path);
   if (ba.Length > 0)
   {
      Assembly dll = Assembly.Load(ba);
      if (dll != null)
      {
         foreach (Type T in dll.GetTypes())
         {
            if (typeof(IMyInterface).IsAssignableFrom(T))
               _classInstance = (IMyInterface)Activator.CreateInstance(T);
         }
      }
   }
}

Используя совет по этому вопросу, я смог определить, что typeof(IMyInterface).Module.FullyQualifiedName возвращает исполняющее приложение (EXE, я отлаживаю). Это, конечно, не соответствует тому, что я вижу для T.Module.FullyQualifiedName, которое является DLL.

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

DonBoitnott 12 нояб. 2014, в 22:14

Источник

1

Может быть, я неправильно понял ваш вопрос, но вы не можете создавать экземпляры интерфейсов - только экземпляры классов, реализующих эти интерфейсы.
xxbbcc 12 нояб. 2014, в 20:45
0

@xxbbcc В этом случае это будет работать, потому что тип, который проходит тест, будет тем, который реализует интерфейс, что делает приведение правильным.
DonBoitnott 12 нояб. 2014, в 20:46
0

Ах, хорошо, я видел это в вашем коде сейчас. Я прокомментировал на основе текста над примером кода. :)
xxbbcc 12 нояб. 2014, в 20:47
0

Вы получаете исключение во время выполнения или _classInstance просто нулевой после выполнения кода?
Philip Pittle 12 нояб. 2014, в 21:13
0

И вы уверены, что IMyInterface приложение ссылается на ту же версию сборки, которая содержит IMyInterface что и mydynamic.dll
Philip Pittle 12 нояб. 2014, в 21:16
0

Где вы объявляете IMyInterface ? Код, который вы показываете, будет работать тогда и только тогда, когда вы имеете дело с одним и тем же типом. Тип, который вы используете в вашем цикле, должен быть того же типа, что и DLL. См. Также раздел Управляемая расширяемость , поскольку он может быть применим к вашему сценарию.
Peter Duniho 12 нояб. 2014, в 21:31
0

@PhilipPittle Нет исключений. Совпадение не найдено, и объект остается null .
DonBoitnott 13 нояб. 2014, в 12:00
0

@PeterDuniho Фактическая декларация в обоих местах. Это объявлено в кодовой странице, которая связана в каждом проекте. Таким образом, как исполняемый EXE- IMyInterface , так и отдельные DLL-библиотеки знают об IMyInterface . Это единственный кусочек клея, на который все полагаются при работе. Это необходимо, потому что EXE должен иметь возможность вызывать стандартный набор методов, оставляя реализацию загруженной DLL.
DonBoitnott 13 нояб. 2014, в 12:02
0

@PeterDuniho Futher, кажется, я заявил, что я понимаю, что он находит тип в двух местах и, таким образом, проваливает совпадение. Вопрос в том, что я могу / должен сделать с этой проблемой.
DonBoitnott 13 нояб. 2014, в 12:02

Показать ещё 7 комментариев

Теги:

c#

reflection

.net-assembly

1 ответ

Ещё вопросы

Может быть, я неправильно понял ваш вопрос, но вы не можете создавать экземпляры интерфейсов - только экземпляры классов, реализующих эти интерфейсы.
@xxbbcc В этом случае это будет работать, потому что тип, который проходит тест, будет тем, который реализует интерфейс, что делает приведение правильным.
Ах, хорошо, я видел это в вашем коде сейчас. Я прокомментировал на основе текста над примером кода. :)
Вы получаете исключение во время выполнения или _classInstance просто нулевой после выполнения кода?
И вы уверены, что IMyInterface приложение ссылается на ту же версию сборки, которая содержит IMyInterface что и mydynamic.dll
Где вы объявляете IMyInterface ? Код, который вы показываете, будет работать тогда и только тогда, когда вы имеете дело с одним и тем же типом. Тип, который вы используете в вашем цикле, должен быть того же типа, что и DLL. См. Также раздел Управляемая расширяемость , поскольку он может быть применим к вашему сценарию.
@PhilipPittle Нет исключений. Совпадение не найдено, и объект остается null .
@PeterDuniho Фактическая декларация в обоих местах. Это объявлено в кодовой странице, которая связана в каждом проекте. Таким образом, как исполняемый EXE- IMyInterface , так и отдельные DLL-библиотеки знают об IMyInterface . Это единственный кусочек клея, на который все полагаются при работе. Это необходимо, потому что EXE должен иметь возможность вызывать стандартный набор методов, оставляя реализацию загруженной DLL.
@PeterDuniho Futher, кажется, я заявил, что я понимаю, что он находит тип в двух местах и, таким образом, проваливает совпадение. Вопрос в том, что я могу / должен сделать с этой проблемой.

DonBoitnott · Answer 1 · 2014-11-13T10-22-00.000Z

Удовлетворение любопытных...

Ответ сводился к небольшой уступке в проекте. Вместо того, чтобы связывать класс интерфейса (кодовую страницу) с каждым проектом и позволять каждому проекту быть его собственным автономным объектом, мне пришлось ссылаться только на этот класс в основном проекте EXE. И вместо того, чтобы включать свои собственные ссылки на IMyInterface, отдельные DLL файлы создают ссылку на сборку для этого проекта EXE.

Это разрешило проблему несовместимости между типом EXE и загруженным типом DLL.

Я говорю "небольшая концессия", потому что дизайн всегда должен иметь DLL в рабочем каталоге EXE, который будет загружен во время выполнения, поэтому ссылка на проект ничего не меняет философски.