NET Remoting和MarshalByRefObject真的死了吗？

Question

我正在做一个需要AppDomain-进程内和进程间-机器内通信的项目。是的..。我知道..。NET Remoting被广泛认为是一种遗留技术，但我面临着两个非常特殊的问题，在这些情况下，WCF可能不是.NET Remoting的完全替代。

1) AppDomain间-进程内通信

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

2)进程间-机器内通信

在这里，我可以肯定地从我的应用程序公开一个WCF服务，并使用命名管道从我的客户端调用该服务。

我真正想做的是从我的应用程序公开一个对象模型，这样我的应用程序就可以从某个网络客户端自动执行，就像Excel公开的OLE/COM自动化对象模型一样。任何COM客户端都可以获取对Excel.Application的对象引用，并查询打开的文档、打开一些新文档等。

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

请原谅我糟糕的英语和我可能是新手的问题。

Answer 1

你可以在这里阅读类似问题的答案：Is .NET Remoting really deprecated?

我可以补充说，我最近使用.NET Remoting进行了相对简单的双向进程间通信，而且几乎是无缝的，所以我可以说，经过这么多年没有得到微软的积极支持，它仍然非常有用。

至于COM，如果您强烈要求您的产品能够被COM客户端访问，我建议通过COM互操作显式地实现COM接口。此外，还有一篇关于同时使用COM和.NET远程处理的有趣文章可能会引起人们的兴趣：http://msdn.microsoft.com/en-us/magazine/cc164085.aspx