我正在开发一个项目，我希望有一个类似System的插件沙箱，但是我遇到了解决双向实时跨进程通信的问题。起初我想到了WCF，因为它可以传递对象元数据，但很快就意识到WCF的服务客户端模型会造成问题。但在我放下我所有的想法和问题之前，我已经计划好了。
我希望有一个主机应用程序来完成大部分工作，让我们称之为host.exe，host.exe将托管该程序的主要应用程序逻辑，以及启动，执行和查杀插件。插件将通过插件代理托管，它将通过MEF托管它们，因此我们将其称为proxy.exe。 proxy.exe将加载插件dll并将它们托管在一个隔离的环境中，这将隔离故障，如果插件失败，它将终止代理而不是应用程序。主机和代理需要在两个方向上实时通信，并且因为将有多个代理主机，所以最好能够传递对象数据。
这是我想要的基本想法。我想到了几种方法。第一个是WCF，但我认为WCF的工作方式很难，如果不是不可能的话，服务的服务器向客户端发送请求/命令。下一个想法是什么使用TCP，并让主机成为TCP服务器并开发一个我可以用来进行通信的消息传递协议，但这会带来一个问题，因为我没有WCF元数据的奢侈品并传递复杂的类信息会是疯了。
通过我的所有研究，我在问题发布之后提出了问题，如果有人能够建议解决这个问题，我将不胜感激。谢谢。
答案 0 :(得分：0)
我的解决方案可能是远程处理。我不知道WCF是否以同样的方式做到这一点。但远程处理可以配置文本，服务器可以随意设置为远程对象。
我想提前警告你。我提到的项目是从很久以前开始的，所以这可能是过时的信息（WCF可能做同样的事情，也可能没有，我的公司没有要求我的任何WCF工作。）
我将我的对象从客户端远程连接到服务器。我会运行服务器（实际上是在一台单独的机器上）然后使用tcp远程处理，我想要的所有对象都将被声明到该应用程序中。
现在这是有趣的部分。远程对象使用非远程委托对象。我会初始化对象（远程），服务器会创建它。然后我将初始化另一个（Interface Typed）对象本地并将其附加到远程对象。
当远程对象想要与我通信时，它会向我发送可序列化的信息，我会将其构建为更多的对象或命令。无论需要什么......（可能更偏远的物体）
无论如何。一个服务器和多个远程对象将与CommonInterface.dll来回发送，其中定义了所有标准接口对象。
这是出于所有意图和目的的盲插件设置，任何希望从我的服务器获取信息的应用程序只要接口匹配就能够实现和处理它们的类。 （带有可序列化的命令数据）
如果插件（客户端）崩溃，那么应用程序（服务器）就不会受到影响。它只会在try catch中将所有通信包装到该插件中，并且远程对象将有一些时间来生存或ping样式释放机制。
我真的不知道你的场景会是什么样的沙盒，但这可能会完成你的要求。
这是一个.net远程聊天服务器。
http://www.codeproject.com/KB/IP/dotnetchatapplication.aspx
这是我第一次使用远程处理构建的相同类型的项目。然后我将它演变成我的服务器插件架构。我和你的使用之间的区别在于服务器是我的客户端是使用服务器的主应用程序，而你的服务器将是允许多个客户端插件的主应用程序。
答案 1 :(得分：0)
在我看来，我建议你使用不同的应用程序域，使用接口与插件进行通信，以及真正的代理对象引用。不要使用不同的进程，可以通过应用程序域隔离实现插件隔离，因为异常不会跨越应用程序域边界，除非指定。
作为替代方案，您可以使用弃用的技术（如.NET Remoting）来进行编组和透明代理对象创建。
在我看来，WCF太重了，太远了实时处理
答案 2 :(得分：0)
进程间通信（IPC）。可能应该称为跨进程通信（CPC）是已知的MS / Windows特定概念。
有关它的更多信息here
过去我使用过RPC和Windows Pipes（在SQL Server中也用于传输大型数据集/结果）
您可以随时尝试其他通信方式，WCF，套接字，发布/订阅消息;例如，TibcoRv（本地会绕过套接字）。 我发现这些有点矫枉过正。但可能完全符合您的要求。