Я динамически загружаю 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.
Я хотел бы разрешить это, не вставляя какую-то промежуточную сборку, которая ничего не делает, кроме как предоставить тип, если это возможно.
Удовлетворение любопытных...
Ответ сводился к небольшой уступке в проекте. Вместо того, чтобы связывать класс интерфейса (кодовую страницу) с каждым проектом и позволять каждому проекту быть его собственным автономным объектом, мне пришлось ссылаться только на этот класс в основном проекте EXE. И вместо того, чтобы включать свои собственные ссылки на IMyInterface
, отдельные DLL файлы создают ссылку на сборку для этого проекта EXE.
Это разрешило проблему несовместимости между типом EXE и загруженным типом DLL.
Я говорю "небольшая концессия", потому что дизайн всегда должен иметь DLL в рабочем каталоге EXE, который будет загружен во время выполнения, поэтому ссылка на проект ничего не меняет философски.