我一直在努力想弄清楚一些事情。所以,我正在寻找建议和研究材料(通过链接)。这是场景:
我们有一个库(例如,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:我从这个片段开始。这将允许我加载包含已安装应用程序(或插件)列表的文件(或脚本)。我可以将此文件创建为 Xml 或二进制格式。安装新应用时,可以添加文件和路径。嗯...我不一定需要使用 MarshalByRefObject。