我一直在努力寻找解决办法。因此，我正在寻找建议和研究 Material (通过链接)。这是场景:
我们有一个库(例如CommonLib)，其中包含其他几个应用程序(例如AppA，AppB，AppC等)所需的资源。现在，此方法的当前运行方式是AppA实例，请检查特定端口是否可用。如果不是，那么它将踢CommonLib(“嘿，醒来”)并启动服务。然后AppA开心了，我们走了。
现在，我对Remoting.Channels进行了大量研究，得出的结论是，我正在启动基于“传统”技术构建的应用程序。好吧...我不喜欢那样。老实说，WCF的开销远远超过了我们的要求，并且未在Mono中完全实现。我们的目标是多平台兼容性(Windows，Mono，Linux)，因此我们正在研究所有选项。
远程处理的想法首先开始，因为我们希望CommonLib成为有保证的单实例(据我了解，单例几乎只能保证是给定AppDomain中的单例-如果我愿意，请随时纠正我是错误的)。无论如何，我意识到了远程处理的力量，因此决定开始进行一些实验性的实现。在最初使用MarshalByRefObject时，我已经取得了成功。但是，我担心这种传统技术的持续实现。
因此，有了所有这些……我正在考虑如何实现CommonLib(作为主机应用程序)，并且在不进行远程处理的情况下，通过Stream，标准TCP Socket或其他方式实现MarshalByRefObject。我在想的是，不是实例化AppA来运行CommonLib，而是将CommonLib实现为基本应用程序。然后，选择要在CommonLib中实例化的应用程序(实际上只是一个“托管” .dll)。然后，CommonLib会将该.dll与托管应用程序使用的任何自定义控件一起加载到CommonLib框架中。带着这个想法，我放弃了(现在)CommonLib必须是真正的单例的要求。
所以...这是我们场景的一个细节。同样，我的问题实际上是两个部分:(a)我应该研究哪种技术，以及(b)我是否需要关注远程技术的传统状态？
任何其他建议，评论或问题都将受到欢迎。
更新1:我从this snippet开始。这将使我能够使用已安装的应用程序(或插件)列表加载文件(或脚本)。我可以以Xml或Binary格式创建此文件。安装新应用后，可以添加文件和路径。嗯...我不一定需要使用MarshalByRefObject。
最佳答案
虽然WCF在Mono中可能不完整，但是Mono 2.6提供了Silverlight/Moonlight所需的一切，因此基于WCF的实现应该是完全可行的。只要您不尝试任何奇特的东西(不同的传输，检查器等)，提供在Windows/mono/等之间可靠的RPC堆栈就应该绰绰有余。
WCF和远程处理之间的主要区别在于用法-远程处理基于一个假装位于不同端的对象，而WCF基于服务；关键是您应该基于离散方法(而不是访问属性等)进行交互-这还具有帮助您在跨越边界时使其明确的优势。
另一种选择是编写一个非常基本的套接字服务器。非常轻巧，您可以使用protobuf-net之类的东西来提供可移植的(跨平台)序列化程序实现(您不应该真正信任两者之间的BinaryFormatter-这是... flakey)。
简而言之-我根本不会围绕MarshalByRefObject进行构建；我将编写一个服务层，例如:
interface IMyService {
void Method1();
int Method2(string s);
}
并从调用者那里提取这些详细信息。如果最终使用了WCF，那么这就是您所需要的。对于现有的远程支持，我将编写一个
IMyService实现，该实现(私有(private)地)封装了整个MarshalByRefObject故事。同上，如果我写了一个套接字服务器。