Does someone have an example of why I would self-host a WCF service

Question

I guess my mind is so engaged in IIS and web applications that I can't think of a reason to go through the trouble of using a self-hosted WCF service. I have always had the availability of IIS so creating a self-hosted WCF service seems like more work than I would want to do. Why would I want to do this?

Answer 1

Lots of points:

• no need for IIS - this can be a great plus on certain servers
• you get to completely define the service addresses - with IIS, they're dictated by server name, name of the virtual directory, plus the name and extension of the SVC file (e.g. http://server/virtualdir/yourservice.svc, while with self-hosting you can use http://Server:7171/Services/MegaService or whatever you like)
• no risk of running into issues related to app pools being recycled (this can be lessened significantly by using separate dedicated app pools for your WCF services)
• ability to stop and start the NT services, thus e.g. taking those services offline for a bit (less easily done with IIS, I believe)
• more control over the creation and the options for the ServiceHost
• support for all protocols out of the box - netTcpBinding etc. requires additional steps (which might be forgotten) on IIS7 and are impossible to do on IIS6

Answer 2

For example lets consider advantages of hosting in windows service:

• Controlled process lifetime
• Application scope
• Supported on all versions of Windows
• also you are not tied only to HTTP if you are using Windows 2003 and below (without WAS)

You can consider also

• Is easy to debug: Debugging WCF services that are hosted in a self-hosted environment provides a familiar way of debugging, without having to attach to separate applications that activate your service.
• Is easy to deploy: In general, deploying simple Windows applications is as easy as xcopy. You don’t need any complex deployment scenarios on server farms, and the like, to deploy a simple Windows application that serves as a WCF ServiceHost.

Answer 3

It's all about how you want to use WCF. Not always the logic you want exposed as a service needs to/can be hosted in IIS. For example:

• you are using WCF to build a P2P channel between multiple instances of your client app on the local network.
• you are building a local WCF service that is deployed on a client SKU, where IIS is not installed by default
• you want complete control of your endpoint addresses
• you want to use net.tcp or net.pipe channels
• you want full control over the lifetime and instance model of your service
• you want the service to be running as the interactive user (impersonation is not always the answer)

Answer 4

One example use case would be client applications. You might self-host a WCF service in the client application so that the client can receive notifications from a backend system.

Answer 5

If you are running 64-bit Windows, you cannot compile and run a WCF Service automatically, you have to self host.

I asked about one particular situation here: http://stackoverflow.com/questions/2804818/ways-to-access-a-32bit-dll-from-a-64bit-exe

I had a 64-bit application that required the use of a 32-bit DLL. So I thought I would just wrap the 32-bit DLL in a 32-bit WCF Service. No go. I couldn't force the service to run 32-bit. Had to self host.

Answer 6

High loaded services net.tcp or net.pipe bindings are not for IIS at all. Its will works only with IIS 7 + additional 3 services: WAS, Net.* Listening adapter & Port Sharing (event if you do not use sharing). It is very complex solution. You must config port sharing, but it will crash some day with socket or pipe error. SelfHost will not.

IIS is not for streaming. You will not work "directly with network stream". You will work with memory buffers or temp files, so you will not benefit from streaming.

P.S. It's all about WCF 3.5 & IIS 7.5. I hope next versions will be much better.