有人举例说明我为什么要自我托管WCF服务

Question

我想我的想法是如此专注于IIS和Web应用程序，我无法想到使用自托管WCF服务的麻烦。我一直有IIS的可用性，因此创建一个自托管的WCF服务似乎比我想要的工作更多。我为什么要这样做？

Answer 1

很多要点：

• 不需要IIS - 这在某些服务器上可能是一个很好的优势
• 您可以完全定义服务地址 - 使用IIS，它们由服务器名称，虚拟目录的名称，以及SVC文件的名称和扩展名（例如http://server/virtualdir/yourservice.svc）决定，而使用自身托管你可以使用http://Server:7171/Services/MegaService或任何你喜欢的东西）
• 没有遇到与回收应用程序池相关的问题的风险（通过为WCF服务使用单独的专用应用程序池可以显着减少这种情况）
• 停止和启动NT服务的能力，例如将这些服务脱机一点（我相信不太容易使用IIS）
• 更多地控制ServiceHost
的创建和选项
• 支持开箱即用的所有协议 - netTcpBinding等在IIS7上需要额外的步骤（可能会被遗忘）并且无法在IIS6上执行

Answer 2

例如，让我们考虑在Windows服务中托管的优势：

• 受控制的流程寿命
• 申请范围
• 在所有版本的Windows上受支持
• 你也不仅仅依赖于HTTP 您正在使用Windows 2003及更低版本 （没有WAS）

你也可以考虑

• 易于调试：调试WCF 托管在的服务 自托管环境提供了一个 熟悉的调试方式，没有 不得不分开 激活你的应用程序 服务。
• 易于部署：一般来说， 部署简单的Windows应用程序 就像xcopy一样简单。你不需要 任何复杂的部署方案 要部署的服务器场等 一个简单的Windows应用程序 作为WCF ServiceHost。

Answer 3

这都是关于如何使用WCF的。并非总是希望作为服务公开的逻辑需要/可以在IIS中托管。例如：

• 您正在使用WCF在本地网络上的多个客户端应用实例之间构建P2P通道。
• 您正在构建部署在客户端SKU上的本地WCF服务，默认情况下不安装IIS
• 您希望完全控制端点地址
• 您想使用net.tcp或net.pipe渠道
• 您希望完全控制服务的生命周期和实例模型
• 您希望服务作为交互式用户运行（模拟并不总是答案）

Answer 4

如果您运行的是64位Windows，则无法自动编译和运行WCF服务，您必须自行托管。

我在这里询问了一个特殊的情况： Ways to access a 32bit DLL from a 64bit exe

我有一个需要使用32位DLL的64位应用程序。所以我想我只是将32位DLL封装在32位WCF服务中。不行。我无法强制服务运行32位。不得不自己主持。

Answer 5

一个示例用例是客户端应用程序。您可以在客户端应用程序中自托管WCF服务，以便客户端可以从后端系统接收通知。

Answer 6

高负载服务net.tcp或net.pipe绑定根本不适用于IIS。 它仅适用于IIS 7 +额外的3项服务：WAS，Net。*听力适配器＆amp;端口共享（如果不使用共享，则为事件）。这是非常复杂的解决方案。您必须配置port sharing，但有一天它会因套接字或管道错误而崩溃。 SelfHost不会。

IIS不适用于流式传输。 您不会“直接使用网络流”。您将使用内存缓冲区或临时文件，因此您不会从流式传输中受益。

P.S。这都是关于WCF 3.5＆amp; IIS 7.5。我希望下一版本会好得多。