可扩展（插件/插件）WCF服务主机的想法？

Question

我正在寻找有关如何构建可扩展WCF服务器（具有动态加载服务）的建议，最好使用System.Addins或MEF。

服务器应该托管实现最小“插件”API（StartService / StopService / GetStatus？/ etc）的任何WCF服务（包含在运行时加载的DLL程序集中）。

This post是一个好的开始。一些目标和要点进行讨论：

• 对每项服务使用/不使用隔离的AppDomain吗？
• 如何配置每项服务（端点，传输协议）？ XML配置文件还是更好的选择？
• 程序集的延迟/延迟加载（当服务请求到达时）？可能？有用？怎么样？
• 磁盘上的文件更改时的程序集重新加载（对开发环境有用）;
• 磁盘上的配置更改时服务重新启动;

当然，其他想法总是受欢迎的;）

Answer 1

• 是的，为每项服务使用隔离的AppDomain。您需要AppDomain隔离，以便您不会删除在发生故障时正在运行的其他服务。

• 通过编程或通过配置提供WCF当前所做的所有方式。由于ServiceHost实例不可序列化，因此编程访问很困难，因此跨应用程序域边界获取信息将会非常痛苦。

• 我想说有可能做到。但是，这基本上是复制Windows Process Activation Service，因此您可能希望开始寻找您的功能。

• 这对开发很有帮助，但老实说，我认为这不是一个重要的功能。它使代码变得复杂，以获得不太可测量的增益（IMO）。我宁愿编写一个脚本来停止服务，复制文件，然后重新启动它，而不是使代码库过于复杂，并且总是不得不观察组件。

• 现在你在谈论IIS。实际上，您可以让IIS托管您的服务，并在配置文件更改时将其回收。

所有这一切，似乎WAS和IIS为您提供了大部分您想要的东西（高度可用，隔离的应用程序域，配置等等），所以您可能想问为什么您想要自己这样做