WCF: service hosting outside of IIS makes IIS an atrophy [closed]

开发者_JS百科 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 12 years ago.

It appears MS is shooting itself in the leg allowing hosting of WCF services outside of IIS. IIS is relatively simple but yet redundant layer for services from my perspective. Introduction of WCF tremendously simplifies service hosting making IIS an atrophy. So what do you think? I am missing something? Why would I use IIS for WCF services? Because I don't see a reason.

---

Hosting inside IIS has its advantages if you want to ie. use the underlying asp.net framework for authentication and authorization. Remember that this requires the AspNetCompatibilityRequirementsMode attribute to be set to Required. This also gives you access to HttpContext.Current for easy retrieval of post-values, cookies and such.

http://msdn.microsoft.com/en-us/library/ms734710.aspx

• WCF services hosted in IIS are deployed and managed like any other type of IIS application, including ASP.NET applications and ASMX.
• IIS provides process activation, health management, and recycling capabilities to increase the reliability of hosted applications. Accessing the Health Monitoring Features allows you to monitor the status of your web application.
• Like ASP.NET, WCF services hosted in ASP.NET can take advantage of the ASP.NET shared hosting model where multiple applications reside in a common worker process for improved server density and scalability.
• WCF services hosted in IIS use the same dynamic compilation model as ASP.NET 2.0, which simplifies development and deployment of hosted services.

---

I agree somewhat. Despite the many advantages Pauli mentions in his post (+1 for that), I see several reasons not to choose IIS for WCF:

• Net* Bindings: IIS does not natively support non-HTTP/S bindings, such as the (very useful) NetTcpBinding, NetNamedPipeBinding and NetMsmqBinding. You can use Windows Process Activation, but that's not really IIS anymore. Also, older versions of IIS don't have WAS, and so do not support non-HTTP/S bindings at all.
• Configuration & Deployment: There is a large configuration overhead to IIS (and WAS) which may not be justified given the deployment scenario of your service.
• Dependency & Testing: Using IIS (or WAS) creates an additional dependency on those components. IIS is notorious for only supporting a specific version for each Windows version, and testing your service with many different versions can easily become a burden. An exact version of the .NET Framework can be deployed on a machine and self-hosting ensures that there a minimum number of variables.
• Ease of Use: The above mentioned configuration, deployment and dependency issues could prove to be a major and sometimes unnecessary learning curve, especially for non-HTTP/S services.
• Flexibility: If you already have a .NET application running as a Windows service, you can just host WCF in it without requiring additional administration effort - if someone's already keeping your service up, then WCF will be up along with it.

---

I disagree as of now i.e. IIS 7/7.5 in Windows Server 2008/2008R2. Yes in IIS 6 you had valid reason to host outside IIS (e.g. if you are using net.tcp binding). But IIS gives you better authentication, load balancing, fault tolerance, monitoring etc than possible easily with self hosting. e.g. I never managed to get SSL with client certs working properly with a self hosted service. Or try restricting based on IP address etc. The URL for services ending with .svc is also not valid as of WCF 4.0. Another advantage is most sysadmins are familiar with IIS admin manager and all settings in web.config can be changed easily for operational support from the GUI. Deployment has been made easier, you can basically clone a IIS site from staging to production. With Appfabric extensions of IIS you get very detailed monitoring and dashboard of your service calls (like calls/sec, failed calls/sec, avg call duration etc.), service call persistence for workflow hosted services etc. You can also monitor all your IIS sites for a whole company from one central console and I think there is even a integration of appfabric with SCOM

In a nutshell I believe for enterprise level hosting IIS & Appfabric should be chosen hosting for WCF services.