An important difference between WCF hosting in IIS and hosing in Windows Service

2011-08-02

The answer is what I am looking for these days. I thought the imporant difference should be like this, but I got the confirmation today:

Hosing in IIS. When a request comes in, the ServiceHost is constructed, then the service class being hosted is instantiated, and the request is handled. Nothing needs to be running around the clock. But at the same time, this setup requires more time and effort every time a message comes in, and you as a programmer don't have much control over your service host, really.

…

Self-hosting is often times faster, since your ServiceHost is already up and running - but it's up to you to make sure it really is up and running, there's no "on-demand" loading whenever a message comes in - either it's up and can service the request, or not. But you have a lot more control over the service host - when and how it's constructed etc., and you get to pick and define your service addresses as you see fit.

I personally would almost always choose to use self-hosting - in a console app for testing, in a NT service for production. To me, it just seems the more appropriate way to do it, and the more controlled way, too. You have to do more work - but you know exactly what you're doing.

Above content form here.

But, there is a news we should know: There is an always-on option for IIS7.5 (WS2008 R2) for on-demand loading in IIS.