从VB6通过COM和远程处理到.NET ......什么乱七八糟的！ [英] From VB6 to .net via COM and Remoting...What a mess!

问题描述

我有一些需要跟我的.Net引擎应用传统的VB6应用程序。 发动机提供可经由.NET远程被连接到一个接口

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.

现在我有一个存根类库，包装所有的接口公开的类型。该存根的目的是将我的.NET类型为COM友好的类型。当我运行这个类库作为控制台应用程序，它能够连接到发动机，调用各种方法，并成功返回的包裹的类型。

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.

在链中的下一个步骤是允许我的VB6应用程序来调用此COM启用存根。 这很好地满足我的主要引擎条目类型（IModelFetcher其包装为COM_ModelFetcher）。然而，当我试图得到任何模型读取器的模型类型（IClientModel，包装为COM_IClientModel，IUserModel，包装为COM_IUserModel等），我得到了以下异常：

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

的第一件事，当我看到这是为了处理AppDomain.CurrentDomain.AssemblyResolve'事件，这让我加载所需的组件。不过，我还是现在得到这个例外。我的AssemblyResolve事件处理程序加载3组件正确，我可以证实，它不会在此之前的异常调用。

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?!

这似乎是与跨远程边界的拉类型。例如，我可以创造一个COM_Client对象，并发送由存根VB6的。这工作绝对没问题。 但同样的方法中，如果我尝试并使用发动机（远程）获得客户端，方法失败，出现相同的异常。我甚至试图返回的对象 - 的调用引擎引发异常只是行为...

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...

虽然我用的是AssemblyResolve方法加载dll文件在运行时，这是不够的。把DLL文件中的C：\ Program Files文件\的Microsoft Office \ OFFICE12文件夹（连同MSACCESS.EXE）解决了这个问题。

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...

这篇关于从VB6通过COM和远程处理到.NET ......什么乱七八糟的！的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！