从 VB6 通过 COM 和 Remoting 到 .net...真是一团糟!
我有一些旧版 vb6 应用程序需要与我的 .Net 引擎应用程序通信。 该引擎提供了一个可以通过.net Remoting 连接的接口。
现在我有一个存根类库,它包装了接口公开的所有类型。此存根的目的是将我的 .net 类型转换为 COM 友好的类型。当我将此类库作为控制台应用程序运行时,它能够连接到引擎、调用各种方法并成功返回包装的类型。
链中的下一步是允许我的 VB6 应用程序调用此 COM 启用的存根。 这对于我的主引擎条目类型(IModelFetcher,它被包装为 COM_ModelFetcher)工作得很好。但是,当我尝试获取任何模型获取器的模型类型(IClientModel,包装为 COM_IClientModel,IUserModel,包装为 COM_IUserModel 等)时,我得到以下异常:
[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。这绝对没问题。 但在同一方法中,如果我尝试使用(远程处理)从引擎获取客户端,该方法将失败并出现相同的异常。我什至没有尝试返回对象 - 只是调用引擎的行为引发了异常......
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...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我发现了问题...
即使我使用 AssemblyResolve 方法在运行时加载 dll,但这还不够。将 DLL 放入“C:\Program Files\Microsoft Office\Office12”文件夹(与 MSAccess.exe 一起)解决了问题。
现在我只需要想出一个比这更优雅的解决方案......
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...