WCF：服务托管IIS以外使IIS的萎缩
看来MS是搬起石头砸自己的腿允许IIS以外的WCF服务托管。从我的角度来看，IIS相对比较简单，但对于服务来说却是冗余层。 WCF的引入极大地简化了使IIS陷入萎缩的服务托管。所以你怎么看？我错过了什么？为什么我会使用IIS进行WCF服务？因为我没有看到一个理由。WCF：服务托管IIS以外使IIS的萎缩
内IIS托管，如果你想，即有它的优势。使用底层的asp.net框架进行认证和授权。请记住，这要求AspNetCompatibilityRequirementsMode属性设置为必需。这也使您可以访问HttpContext.Current，以便轻松检索后值，Cookie等。
http://msdn.microsoft.com/en-us/library/ms734710.aspx
- 在IIS托管WCF服务的部署，就像任何其他类型的IIS应用程序，包括ASP.NET应用程序和ASMX管理。
- IIS提供进程激活，健康管理和回收功能，以提高托管应用程序的可靠性。访问Health Monitoring Features可让您监视Web应用程序的状态。
- 像ASP.NET，ASP.NET中的托管可以利用ASP.NET的WCF服务共享主机多个应用程序驻留在为提高服务器的密度和可扩展性普通工人的过程模型。
- 在IIS托管WCF服务使用相同的动态编译模型ASP.NET 2.0，它简化了开发和托管服务的部署。
我同意有些。尽管有许多优点圣保利提到了他的岗位（+1为），我看到几个理由不选择IIS的WCF：
- 净*绑定： IIS本身不支持非HTTP/S绑定诸如（非常有用的）NetTcpBinding,NetNamedPipeBinding和NetMsmqBinding。你可以使用Windows Process Activation，但那不再是真正的IIS了。此外，旧版本的IIS没有WAS，因此根本不支持非HTTP/S绑定。
- 配置&部署： IIS（和WAS）的配置开销很大，考虑到服务的部署方案，这可能不合理。
- 依赖关系&测试：使用IIS（或WAS）会在这些组件上创建额外的依赖关系。 IIS仅支持每个Windows版本的特定版本而臭名昭着，并且使用许多不同版本测试您的服务很容易成为一种负担。 .NET Framework的确切版本可以部署在一台机器上，而自托管功能可以确保最少数量的变量。
- 易于使用：上述配置，部署和依赖性的问题可能被证明是一个重大的，有时甚至多余的学习曲线，尤其是对非HTTP/S服务。
- 灵活性：如果您已经有一个作为Windows服务运行的.NET应用程序，那么您可以在其中托管WCF而无需额外的管理工作 - 如果某人已经保留了您的服务，那么WCF将随之启动。
我不同意到现在，即Windows Server 2008/2008R2中的IIS 7/7.5。是的，在IIS 6中，您有正当的理由来托管IIS以外（例如，如果您使用net.tcp绑定）。但IIS为您提供了更好的身份验证，负载平衡，容错，监控等方面的可能性，而不像自己托管那样简单例如我从来没有设法使用客户端证书与自我托管服务正常工作的SSL。或者尝试根据IP地址进行限制等。以.svc结尾的服务的URL在WCF 4.0中也是无效的。另一个优点是大多数系统管理员都熟悉IIS管理员管理器，并且可以通过GUI轻松更改web.config中的所有设置以获得操作支持。部署已经变得更容易了，你基本上可以从一个IIS站点克隆到生产环境。使用IIS的Appfabric扩展，您可以获得非常详细的服务调用监视和控制面板（如调用/秒，失败调用/秒，平均调用持续时间等），用于工作流托管服务的服务调用持久性等。您还可以监控所有IIS和站点为整个公司从一个*控制台我觉得这是即使SCOM
一个集成的AppFabric的概括地说，我相信企业级托管IIS &应的AppFabric托管WCF服务进行选择。
IIS是微软手头上唯一的通用主机 - 但我认识的大多数WCF专家（例如Juval Lowy）都认为**永远不会**使用IIS来托管生产级WCF服务。我总是把我的生产WCF服务放入自托管的NT服务中。 – 2011-01-13 07:34:15
@marc_s：+10如果我可以的话。 – Schultz9999 2011-01-13 07:40:39
@marc_s：无法编辑我以前的帖子。只是想提一下，NT服务是在崩溃情况下自动启动和重新启动的好方法。它完全解决了泡利的公告2。 – Schultz9999 2011-01-13 08:09:28