Из VB6 в .net через COM и Remoting ... Какой беспорядок! - PullRequest
1 голос
/ 01 апреля 2010

У меня есть несколько устаревших приложений vb6, которые должны общаться с моим приложением .Net engine. Движок предоставляет интерфейс, к которому можно подключиться через .net Remoting.

Теперь у меня есть библиотека классов-заглушек, которая упаковывает все типы, предоставляемые интерфейсом. Цель этой заглушки - перевести мои типы .net в COM-дружественные типы. Когда я запускаю эту библиотеку классов как консольное приложение, она может подключаться к движку, вызывать различные методы и успешно возвращать упакованные типы.

Следующий шаг в цепочке - разрешить моему приложению VB6 вызывать эту заглушку с поддержкой COM. Это прекрасно работает для моего основного типа записи двигателя (IModelFetcher, который обернут как COM_ModelFetcher). Однако, когда я пытаюсь получить любой из типов модели сборщика моделей (IClientModel, заключенный в COM_IClientModel, IUserModel, заключенный в COM_IUserModel, e.t.c.), я получаю следующее исключение:

 [Exception - type: System.InvalidCastException 'Return argument has an invalid type.'] in mscorlib
   at System.Runtime.Remoting.Proxies.RealProxy.ValidateReturnArg(Object arg, Type paramType)
   at System.Runtime.Remoting.Proxies.RealProxy.PropagateOutParameters(IMessage msg, Object[] outArgs, Object returnValue)
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at AWT.Common.AWTEngineInterface.IModelFetcher.get_ClientModel()
   at AWT.Common.AWTEngineCOMInterface.COM_ModelFetcher.GetClientModel()

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

Может ли кто-нибудь помочь мне отвязаться от этого беспорядка межпроцессного взаимодействия?!

Обновление 1

Кажется, это связано с переносом типов через границу удаленного взаимодействия. Например, я могу создать объект COM_Client и отправить его из заглушки в VB6. Это работает абсолютно нормально. Но в том же методе, если я пытаюсь получить клиент из движка с помощью (удаленного взаимодействия), метод завершается с тем же исключением. Я даже не пытаюсь вернуть объект - просто вызов двигателя выдает исключение ...

1 Ответ

0 голосов
/ 01 апреля 2010

Я нашел проблему ...

Несмотря на то, что я использовал метод AssemblyResolve для загрузки библиотек во время выполнения, этого было недостаточно. Помещение DLL в папку «C: \ Program Files \ Microsoft Office \ Office12» (вместе с MSAccess.exe) решило проблему.

Теперь мне просто нужно придумать более элегантное решение, чем это ...

...