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