是否有任何理由不在COM +应用程序中托管COM服务器？

Question

将进程内COM服务器转换为外部进程COM服务器的最简单方法是创建COM +应用程序。这样做有什么可能的缺点？

Answer 1

我真的想不出任何理由创建自己的容器或使用第三方（如果存在）支持MTS / COM +。我的意思是它完成了你想要的所有事情：

• 让您选择分发 COM对象容器进程。
• 允许您配置帐户 跑下。
• 监控容器 必要时处理并重新启动 并且可以回收它们。
• 甚至允许你 在场景中托管STA组件 你需要多个线程的地方 通过启动多个服务来提供服务 工人流程。等

很难想象如果不花费6个月或更长时间就做得更好。

Answer 2

将问题彻底解决，我猜你的反自我可能会问：“为什么除了COM +服务器之外还有一个用于进程外COM服务器的选项？这些其他托管选项提供了哪些优势？”

我没有准备任何东西，但我正在想象一个表 - 在顶部作为标题在各个列中提供托管选项，并将特定属性作为行中的标题。您可以评估每个不同区域或属性上的每个托管选项。

我看到的主要区别在于管理模型和功能，以及灵活性。例如，在Windows服务中托管COM服务器可以为您提供Windows服务功能 - 自动启动操作系统启动;与services.msc关联的管理UI（管理/操作事物），以及将其他接口添加到该服务的灵活性（灵活性）。