是否“纯粹”？ IDispatch 接口需要代理/存根 DLL？
..对于进程外服务器，或者我可以在不注册代理/存根的情况下调用调度接口吗？
所讨论的界面水平非常高，因此性能不是问题，而且我可以使整个过程免注册，这是一个很大的优点
..for an out-of-process-server, or can I call a dispatch interface without registering a proxy/stub?
The interface in question is very high level, so performance is a non-issue, and I could make the whole thing registration-free, which is a big plus
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我非常确定，如果您将接口限制为自动化兼容类型，则不需要提供自定义代理/存根 DLL。 在这种情况下，系统可以使用自动化封送拆收器并且不需要任何额外的帮助。 我相信自动化兼容类型是可以适合
VARIANT的类型，例如简单的 POD 类型、BSTR等。我发现这篇知识库文章对自动化封送拆收器进行了一些讨论，尽管它并不是专门针对您的问题。 它至少列出了兼容的类型。 它还提到您需要在组件注册中专门识别自动化封送拆收器，但根据我的经验，这是没有必要的 - 您的情况可能会有所不同。
最后，您可能还需要实现 IProvideClassInfo； 我通常使用ATL提供的实现。
I'm pretty sure you don't need to provide a custom proxy/stub dll if you limit your interface(s) to automation-compatible types. In that case, the system can use the automation marshaler and doesn't need any additional help. I believe the automation-compatible types are the types that can fit into a
VARIANT, e.g. simple POD types,BSTRs, and the like.I found this KB article which has some discussion of the automation marshaler, although it's not specifically targeted at your question. It does list the compatible types, at the very least. It also mentions that you need to specifically identify the automation marshaler in the registration for your component, but in my experience this isn't necessary - your mileage may vary.
Lastly, you may need to implement IProvideClassInfo as well; I usually use the implementation provided by ATL.
如果您的接口需要编组，则仅需要代理/存根 DLL。 这意味着如果您的 COM 服务器正在运行，并且接口不在公寓之间传递，并且您不会从 .Net 或任何其他需要对其进行编组的情况调用它，那么您不需要代理/存根 DLL。
You only need a proxy/stub dll if your interface needs to be marshalled. This means if your COM server is in process, and the interface is not passed between apartments, and you aren't going to be calling it from .Net or any other situation that would require it to be marshalled, then you do not need a proxy/stub dll.