有人有一個爲什麼我會自我託管WCF服務的例子

Question

我想我的思想是如此從事IIS和Web應用程序，我想不出一個理由來解決使用自託管WCF服務。我一直都有IIS的可用性，所以創建一個自託管的WCF服務似乎比我想要做的更多的工作。我爲什麼要這樣做？

Answer 1

很多要點：

• 不需要IIS - 這可能是某些服務器上的一個偉大的加
• 你完全定義服務地址 - 與IIS，它們是由服務器名決定，虛擬目錄的名稱，以及SVC文件的名稱和擴展名（例如http://server/virtualdir/yourservice.svc，同時使用自託管，您可以使用http://Server:7171/Services/MegaService或任何您喜歡的）
• 沒有遇到與正在回收的應用程序池相關的問題的風險這可以通過爲您使用單獨的專用應用程序池而顯着減輕r WCF服務）
• 停止和啓動NT服務的能力，例如，服用這些服務離線位（不太容易用IIS做，我相信）在創建
• 更多的控制權，併爲所有協議開箱的ServiceHost
• 支持的選項 - NetTcpBinding的等需要額外的步驟（這可能是在IIS7忘了），並且不可能在IIS6做

Answer 2

例如可以考慮在Windows服務託管的優勢：

• 控制過程的生命週期
• 應用範圍
• 支持Windows
的所有版本
• 此外，如果 您使用的是Windows 2003和下方 （不WAS）

你不依賴只有HTTP您還可以考慮

• 易於調試：調試WCF 託管在 自託管環境中的服務提供了一種熟悉的調試方式，沒有 必須附加到單獨的 應用程序來激活您的 服務。
• 易於部署：通常，部署簡單Windows應用程序 的 與xcopy一樣簡單。您不需要 服務器場等的任何複雜部署方案，以便將 用作WCF ServiceHost的簡單Windows應用程序。

Answer 3

這一切都是關於你想如何使用WCF。並不總是您想要暴露的邏輯，因爲服務需要/可以託管在IIS中。例如：

• 您正在使用WCF在本地網絡上的客戶端應用程序的多個實例之間構建P2P通道。
• 你正在建設
• 你希望你的端點地址的完全控制被部署在IIS默認是不安裝在客戶端SKU，在本地WCF服務
• 要使用的net.tcp或net.pipe渠道
• 你想
• 你希望服務運行的交互式用戶（模擬並不總是回答）在你的服務的生命週期和實例模型完全控制

Answer 4

一個例子的用例是客戶端應用。您可以在客戶端應用程序中自行託管WCF服務，以便客戶端可以從後端系統接收通知。

Answer 5

如果您正在運行64位Windows，則無法自動編譯和運行WCF服務，您必須自行託管。

我在這裏問關於一個特殊情況： Ways to access a 32bit DLL from a 64bit exe

我有需要使用一個32位的DLL的64位應用程序。所以我想我只是將32位DLL包裝在32位WCF服務中。不行。我無法強制該服務運行32位。必須自己主持。

Answer 6

高負載的服務net.tcp或net.pipe綁定根本不適用於IIS。 它只能在IIS 7 +附加的3個服務上運行：WAS，Net。*偵聽適配器&端口共享（如果您不使用共享，則爲事件）。這是非常複雜的解決方案。您必須配置port sharing，但它會因套接字或管道錯誤而崩潰。 SelfHost不會。

IIS不適用於流式傳輸。 你不會「直接與網絡流」工作。您將使用內存緩衝區或臨時文件，因此您不會受益於流式傳輸。

P.S.這完全是關於WCF 3.5 & IIS 7.5。我希望下一個版本會更好。