I'm working on a project using Windows 2008, .NET 3.5 and WCF for some internal services and the question of how to host the services has arisen.

Since we're using Windows 2008 I was thinking it'd be good to take advantage of Windows Process Activation Service (WAS) although the feeling on the project seems to be that using Windows Services would be better.

So what's the low down on using WAS to host WCF services in comparison to a Windows Service? Are there any real advantages to using Windows Services or is WAS the way to go?

+10  A: 

Recently I had to answer very similar question and these are the reasons why I decided to use IIS 7.0 and WAS instead of Windows Service infrastructure.

  1. IIS 7.0 is much more robust host and it comes with numerous features that make debugging easy. Failed requests tracing, worker process recycling, process orphaning to name a few.
  2. IIS 7.0 gives you more option to specify what should happen with the worker process in certain circumstances.
  3. If you host your service under IIS it doesn't have a worker process assigned to it until the very first request. This is something that was a desired behaviour from my perspective but it might be different in your case. Windows Service gives you the ability to start your service in a more deterministic way.
  4. From my experience WAS itself doesn't provide increased reliability. It's biggest advantage is that it exposes the richness of IIS to applications that use protocols different than HTTP. By different I mean: TCP, named pipes and MSMQ.
  5. The only disadvantage of using WAS that I'm aware of is that the address your service is exposed at needs to be compliant with some sort of pattern. How it looks like in case of MSMQ is described here
Pawel Pabich
Good info. What about the disadvantages though? My understanding is that using WAS precludes doing TCP bindings. Is this true?
Kent Boogaart
Not exactly. WAS allows you to use TCP bindings, while IIS versions prior to 7 only supported HTTP bindings.