NET Remoting和MarshalByRefObject真的死了吗？

Question

我正在开发一个需要AppDomain进程间进程和进程间进程内部通信的项目.是的......我知道...... NET Remoting被广泛认为是一种传统技术,但我面临两个非常特殊的问题,也许在这些情况下,WCF并不是NET Remoting的完全替代品.

1)app -main进程间进程内通信

我正在开始的应用程序启动,需要搜索并加载一个更多的插件.我希望在单独的AppDomain中加载每个插件.我需要一种方法在他的AppDomain中创建每个Addin实例,并在某个时刻调用此实例的一些接口方法.NET Remoting是唯一的方法,对吧？此外,如果我们希望应用System.Addins范例,显然只基于NET Remoting并且没有标记为过时...

2)进程间 - 机器内通信

在这里,我可以肯定地从我的应用程序中公开WCF服务,并使用命名管道从我的客户端调用此服务.

我真正想做的是从我的应用程序中公开一个对象模型,这样我的应用程序就可以从一些.NET客户端自动化,就像Excel公开的OLE/COM Automation对象模型一样.任何COM客户端都可以获得对Excel.Application的对象引用,并查询打开的文档,打开一些新文档等等.

我认为WCF以独立于平台的方式进行通信是很好的.但在这种情况下,我只需要在同一台机器上从Net客户端与Net应用程序进行通信.我认为,WCF服务哲学不允许使用对象,集合,字段,静态成员,方法重载来公开富对象模型......或者我错了？

请原谅我的坏英语和我的新手问题.

Answer 1

您可以在此处阅读类似问题的答案：.NET Remoting 真的已弃用吗？

我可以补充一点，我最近使用 .NET Remoting 进行相对简单的双向进程间通信，并且一切都几乎无缝进行，因此我可以说，在多年来没有得到 Microsoft 的积极支持之后，它仍然非常有用。

至于 COM，如果您强烈要求 COM 客户端可以访问您的产品，我建议通过 COM 互操作显式实现 COM 接口。另外，还有一篇关于一起使用 COM 和 .NET Remoting 的有趣文章，您可能会感兴趣：http://msdn.microsoft.com/en-us/magazine/cc164085.aspx