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

Question

將進程內COM服務器轉換為進程外COM服務器的最簡單方法是創建COM +應用程序。 這樣做有什么可能的缺點？

Answer 1

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

• 允許您選擇COM對象到容器進程的分發。
• 允許您配置它們運行的​​帳戶。
• 監視容器進程並在必要時重新啟動並可以回收它們。
• 甚至允許您在需要通過啟動多個工作進程來處理多個線程的情況下托管STA組件。 等等

如果不花費6個月或更長時間，很難想象做得比這更好。

Answer 2

把問題徹底解決了，我想你的反自我可能會問：“為什么除了COM +服務器之外還有一個用於進程外COM服務器的選項？這些其他托管選項提供了哪些優勢？”

我沒有准備好任何東西，但我想象的是一個表 - 在頂部作為標題在各個列中提供托管選項，並將特定屬性作為行中的標題。 您可以評估每個不同區域或屬性上的每個托管選項。

我看到的主要區別在於管理模型和功能，以及靈活性。 例如，在Windows服務中托管COM服務器可以為您提供Windows服務功能 - 自動啟動操作系統啟動; 與services.msc關聯的管理UI（管理/操作事物），以及將其他接口添加到該服務的靈活性（靈活性）。