我正在开发一个需要跨 AppDomain-intra-process 和 inter-process-intra-machine 通信的项目。是的...我知道... NET Remoting 被广泛认为是一种遗留技术，但我面临两个非常特殊的问题，也许在这些情况下，WCF 不能完全替代 NET Remoting。
1)跨AppDomain-进程内通信
我正在开发的应用程序启动并且需要在更多插件上搜索和加载一个。我希望将每个插件加载到单独的 AppDomain 中。我需要一种方法来在他的 AppDomain 中创建每个 Addin 实例，并在某个时候调用该实例的一些接口(interface)方法。这里 NET Remoting 是唯一的方法，对吧？此外，如果我们希望应用 System.Addins 范式，显然仅基于 NET Remoting 并且没有标记为过时......
2)进程间机器内通信
在这里，我可以肯定地从我的应用程序中公开 WCF 服务，并使用命名管道从我的客户端调用此服务。
我真正想做的是从我的应用程序中公开一个对象模型，以便我的应用程序可以从一些 NET 客户端自动化，就像 Excel 公开的 OLE/COM 自动化对象模型一样。任何 COM 客户端都可以获取对 Excel.Application 的对象引用并查询打开的文档、打开一些新文档等。
我认为 WCF 很适合以独立于平台的方式进行交流。但在这种情况下，我只需要在同一台机器上从 Net 客户端与 Net 应用程序进行通信。我认为，WCF 服务哲学不允许公开具有对象、集合、字段、静态成员、方法重载的丰富对象模型......或者我错了？
请原谅我糟糕的英语和我可能是新手的问题。
最佳答案
您可以在此处阅读类似问题的答案:Is .NET Remoting really deprecated?
我可以补充一点，我最近使用 .NET Remoting 进行了相对简单的双向进程间通信，并且几乎无缝进行，所以我可以说它在多年来没有得到 Microsoft 的积极支持之后仍然非常有用。
至于 COM，如果您对 COM 客户端可以访问您的产品有强烈要求，我建议通过 COM 互操作显式实现 COM 接口(interface)。此外，还有一篇关于同时使用 COM 和 .NET Remoting 的有趣文章，您可能会感兴趣:http://msdn.microsoft.com/en-us/magazine/cc164085.aspx
关于wcf - NET Remoting 和 MarshalByRefObject 真的死了吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10064431/