From VB6 to .net via COM and Remoting...What a mess!

I have some legacy vb6 applications that need to talk to my .Net engine application. The engine provides an interface that can be connected to via .net Remoting.

Now I have a stub class library that wraps all of the types that the interface exposes. The purpose of this stub is to translate my .net types into COM-friendly types. When I run this class library as a console application, it is able to connect to the engine, call various methods, and successfully return the wrapped types.

The next step in the chain is to allow my VB6 application to call this COM enabled stub. This works fine for my main engine-entry type (IModelFetcher which is wrapped as COM_ModelFetcher). However, when I try and get any of the model fetcher's model types (IClientModel, wrapped as COM_IClientModel, IUserModel, wrapped as COM_IUserModel, e.t.c.), I get the following exception:

开发者_运维知识库

 [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()

The first thing I did when I saw this was to handle the 'AppDomain.CurrentDomain.AssemblyResolve' event, and this allowed me to load the required assemblies. However, I'm still getting this exception now. My AssemblyResolve event handler is loading three assemblies correctly, and I can confirm that it does not get called prior to this exception.

Can someone help me untie myself from this mess of interprocess communication?!

Update 1

It seems something to do with pulling the types across the remoting boundary. For example, I can create a COM_Client object, and send that from the stub to the VB6. This works absolutely fine. But within that same method, if I try and get the Client from the engine using (remoting), the method fails with the same exception. I'm not even trying to return the object - just the act of calling the engine throws the exception...

---

I've found the problem...

Even though I was using the AssemblyResolve method to load the dlls at runtime, this wasn't enough. Putting the DLLs in the "C:\Program Files\Microsoft Office\Office12" folder (along with MSAccess.exe) solved the problem.

Now I just need to come up with a more elegant solution than that...