我一直在试图想出一些事情。所以，我正在寻找建议和研究材料（通过链接）。这是场景：
我们有一个库（比如CommonLib），它包含其他几个应用程序（比如AppA，AppB，AppC等等）所需的资源。现在，它当前的工作方式是AppA实例，检查特定端口是否可用。如果不是，那么它会踢CommonLib（“嘿，醒来”）并启动服务。然后AppA很高兴我们离开了。
现在，我已经对Remoting.Channels进行了大量研究，我得出的结论是，我正在开发一个基于被认为是“遗留”技术的应用程序。嗯......我不喜欢那样。老实说，WCF比我们需要的开销更多，而且没有在Mono中完全实现。我们的目标是多平台兼容性（Windows，Mono，Linux），因此我们正在研究所有选项。
远程处理的想法首先开始，因为我们希望CommonLib成为一个有保证的单个实例（据我所知，单例几乎只能保证在给定的AppDomain中是一个单例 - 可以随意纠正我，如果我错了）。无论如何，我意识到远程处理的力量，并决定开始一些实验性实施。我最初使用MarshalByRefObject已经成功了。但是，我担心这种传统技术的继续实施。
所以，所有这些...我正在考虑如何实现CommonLib（作为宿主应用程序），并且无需远程处理，通过Stream，标准TCP套接字或其他方式实现MarshalByRefObject。我在想的是，不要实例化AppA以使CommonLib运行，只需将CommonLib实现为基础应用程序。然后，您选择要在CommonLib中实例化的应用程序（实际上只是'托管'.dll）。然后，CommonLib会将.dll加载到CommonLib框架中以及托管应用程序使用的任何自定义控件。除了这个想法，我放弃了（目前）CommonLib必须是真正的单身人士的要求。
所以......这是我们场景的细节。同样，我的问题实际上是两个部分：（a）我应该研究哪些技术，以及（b）我是否需要关注远程技术的遗留状态？
欢迎任何其他建议，意见或问题。
更新1：我从this snippet开始。这将允许我加载一个文件（或脚本），其中包含已安装的应用程序（或插件）列表。我可以创建此文件为Xml或二进制格式。安装新应用时，文件＆amp;路径可以添加。嗯......我不一定需要使用MarshalByRefObject。
答案 0 :(得分：2)
虽然在Mono中WCF可能不是完整的，但Mono 2.6提供了silverlight / moonlight所需的一切，因此基于WCF的实现应该是完全可行的。只要你不尝试任何异国情调（不同的运输工具，检查员等），提供一个在windows / mono / etc之间可靠的RPC堆栈就足够了。
WCF和远程处理之间的关键区别在于用法 - 远程处理基于一个假装处于不同端的对象，其中WCF基于服务;关键是你应该以离散方法为基础进行交互（而不是访问属性等） - 这也有助于在越过边界时使其显式化。
另一种选择是编写一个非常基本的套接字服务器;非常轻量级，你可以使用像protobuf-net这样的东西来提供一个可移植的（跨平台）序列化程序实现（你不应该真正信任两者之间的BinaryFormatter - 它是...... flakey）。
简而言之 - 我根本不会围绕MarshalByRefObject 构建;我会写一个服务层，如：
interface IMyService {
void Method1();
int Method2(string s);
}
并从调用者那里抽象出这些细节。如果你最终使用WCF，那么你需要所有;对于现有的远程支持，我会编写一个IMyService实现，封装（私下）整个MarshalByRefObject故事。如果我写了一个套接字服务器，也可以。
答案 1 :(得分：1)
我不确定WCF会废弃.NET Remoting。我认为他们的用例有些不同; WCF（故意）没有“按引用编组”的概念，因为它是为分布式和（相对）松散耦合的应用程序而设计的，可能需要避免由于延迟等引起的繁琐协议。如果您的组件自然紧密耦合，延迟会很低但是性能需要很高，保留丰富的.NET类型很重要，等等。然后Remoting可能仍然是一个很好的选择。无论如何，我不担心是“遗留”，至少在Windows / .NET上的“遗留”技术有一种方法可以保持相当长的一段时间，如果他们获得相当大的使用量。 Remoting仍然存在于.NET的最新版本（4.0）中。
这并不意味着Remoting必然 最适合您的情况......