Использование наследника MarshalByRefObject для динамической загрузки сборки в AppDomain - проблема с доступом наследника - PullRequest
Новая
       40

Использование наследника MarshalByRefObject для динамической загрузки сборки в AppDomain - проблема с доступом наследника

0 голосов
/ 20 мая 2019

Попытка загрузки сборки в домен приложений через наследник MarshalByRefObject (MBROI) для вызова Assembly.Load / LoadFile через MBROI из контекста нового (динамического) домена. Из моего собственного экземпляра типа AssemblyLoader, который не является MRBOI, я вызываю наследник, чтобы фактически выполнить загрузку.

Я создаю экземпляр MRBOI через CreateInstanceAndUnwrap, вызываемый через динамический домен. Кажется, все это работает. Вопрос, таким образом, ...

Кажется, мне нужно определить MRBOI в том же ФАЙЛЕ, в котором определен мой AssemblyLoader. Я не могу определить его в другом файле, даже если он определен в том же пространстве имен, что и AssemblyLoader. 

FILE:

namespace MyNamespace {

    class MBROI : MarshalByRefObject {
        ... my code to load/access the assembly
    }

    class AssemblyLoader {
        ... my own framework Assembly load "wrapper" to call the MBROI
    }
}

-- end FILE.

Это работает, но ...

Если я вызываю тот же MBROI, определенный в другом файле, но определенный в том же пространстве имен (или любом другом пространстве имен), я получаю сообщение об ошибке:

System.TypeLoadException: «Не удалось загрузить тип« MyNamespace.MBROI »из сборки« MyMainAssembly », версия = 1.0.0.0, культура = нейтральная, PublicKeyToken = null '.'

Есть мысли о том, почему это так? AssemblyLoader и MBROI определены в одной и той же основной сборке root / app. Почему важно, чтобы он был определен в том же файле?

Испытывал кучу разочарований в связи с динамической загрузкой сборок .net. Это «работает» таким образом, но процесс настолько неуклюжий и сопровождается ошибками, что кажется, что это почти что задумано.

Любая помощь с этим очень ценится. Заранее спасибо.

...