Take the 2-minute tour ×

So I'm designing a WCF service. I'm unexperienced with WCF, and I'm trying to decide whether it should be hosted in IIS, or a custom Windows service.. Or some other option?

Things to consider:

  • It needs to load data from a database on startup.
  • It needs to maintain this data across requests, not load it each time.
  • It needs to process multiple requests simultaneously.
  • It needs to be as configurable as possible regarding endpoints.
  • It will be calling native dlls quite a lot.

I suspect hosting it in IIS would simplify certain things, but I'm not sure it would be a good idea in this situation.

What are my options, and what are their pros and cons?

share|improve this question

4 Answers 4

up vote 16 down vote accepted

You need to basically look at three options:

1) Hosting in IIS6 (Windows Server 2003/2003 R2): in this scenario, you can only host HTTP protocols - nothing else. This is quite a limitation in itself, you cannot use e.g. netTcp for Intranet scenarios.

2) Hosting in IIS7 / WAS (Vista, Server 2008): this gives you more option in terms of protocols supported, and the hosting environment looks like a winner at first.

3) Self-hosting: in this scenario, it's totally up to you to do whatever you need to do to host and run your services.

If you throw out option #1 for now (if you only have IIS6 available, I'd always use self-hosting), it's down to IIS7 vs. self-hosting.

IIS7 gives you "activation on demand", e.g. your service code is not in memory at all times, but will be loaded and instantiated once a request comes in. That can be a plus.

On the other hand, hosting in IIS7/WAS robs you of the ability to specify your own endpoints - your endpoint and thus service address is the virtual directory where your "MyService.svc" file lives - period. You cannot change that in any way, shape or form.

Self-hosting might look like a lot of work - but it does give you the best flexibility: you can pick your protocols as you like, you can set up your own addressing scheme the way you like it, and you have total control over what gets done when. You can introduce your own custom ServiceHost if you need to do some extra work to host services, and so on.

Unless you're just playing around with WCF a bit, I would always recommend and vote for self-hosting - if you need to have the WCF service running at all times, inside a Windows NT Service (that's the best solution for production environments), and if you're developing/debugging, you can totally host your WCF services in a console app which you can launch and stop at your leisure.

So to make a long story short: in the end, if you really want control over what's happening, I would always recommend self-hosting.

This might change once the new "Dublin" Server-Addon by Microsoft comes out - sometime after .NET 4 is launched, probably early in 2010 - but that's still too early to tell.

Hope this helps.


share|improve this answer
You really know your WCF. –  Contango Dec 13 '10 at 22:50
@Gravitas: thanks! I've learned from the WCF Master :-) (Juval Lowy) –  marc_s Dec 14 '10 at 6:11
Hello, almost 5 years later, could you update your answer with the latest version of WCF and IIS? Also, do you think that Windows Services Recycling features are as efficient as IIS ones? Thanks! –  Nock Jun 5 at 1:23
@Nock: even today, June 2014, I would still say the same thing - if you want full control, use self-hosting. –  marc_s Jun 5 at 4:57

I prefer self hosted services myself (Windows service). With that said there are valid reasons for going either way.

There are some valuable articles in MSDN regarding different WCF hosting strategies.

Here is a good summary of why you might choose to use IIS as your service host.

share|improve this answer

I would say that without IIS7 and WAS you cannot host anything but HTTP based endpoints using IIS. As such you would most likely want to self host for flexibility.

As for your data considerations, any service can be coded with state such that data is cached etc.

Multiple requests will require you to use WCF concurrency. You want to set attributes on your service host:

[System.ServiceModel.ServiceBehavior(UseSynchronizationContext = false,
    InstanceContextMode = System.ServiceModel.InstanceContextMode.PerCall,
    ConcurrencyMode = System.ServiceModel.ConcurrencyMode.Multiple)]
public class MyService : IMyService

WCF is a big beast, I recommend you have a look at Juval Lowy's book and anything else you can get your hands on, you will not learn it in a day.

share|improve this answer

Maybe a bit off topic but it does address consideration four.

If you end up going with self hosting and need to be as "configurable as possible regarding endpoints" you might want to take a look at Managed Services Engine. MSE is an open source product created by Microsoft Services that lets you virtualize your services. Basically, it is a WCF host that uses metadata from its own repository to expose services. Some features are: support of side by side versioning of services, ability to enable/disable operations on services, ability to map operations to endpoints, ability to apply policies to operations.

I'm not sure if it fits your needs but it's worth taking a look at -- especially if you need to be extremely configurable.

share|improve this answer
MSE is a little old, isn't it? –  John Saunders Aug 4 '09 at 17:46
Yes and no. The latest release was May 2009 so it's being actively developed. But where it fits on the SOA roadmap, I'm not sure (probably nowhere since it's developed by Microsoft Services). –  Randy Levy Aug 4 '09 at 22:19
It's been about 2 years between releases so I will now say that it is a little old. :) –  Randy Levy Jan 27 '11 at 3:48

Your Answer


