The WCF service cannot exist in a void. And because WCF is a Windows technology you will need to set up a windows process of some sorts to host your WCF service.

For this you have three different options.

  1. IIS
  2. WAS
  3. Self- hosting

Actually there is also the fourth possibility of hosting a service InProc. This works similar to the Self-Hosting, which is the reason I will demonstrate it in the section about self-hosting.

As you probably have guessed, each of this has its own strengths and weaknesses. We will in this post dive into those strenghts and weaknesses.

What this post will cover

  • What are those options exactly
  • Advantages/disadvantages of each option
  • When to choose which

What this post will not cover

  • Use and configuration of IIS
  • Use and configuration of WAS
  • details on IIS, WAS WCF hosting (I use it mostly with self hosting)


There is no alternative to setting up a windows proces to host your WCF services.


The Internet Information Service can be used to host your WCF service. Where as the IIS as a web server spins up your service with the first client request that reaches it. Becuase it is a full blown web server it actually manages the whole lifecycle of your application, as well as spinning up threads (in conjunction with the WCF runtime).

To host one WCF service on an IIS you need to provide the IIS with similar information as if you would host an ASP.Net Web Api. This means you will need to provide a virtual directory in the IIS, supply a .svc file and configure your service, that it uses the same baseAddresses as that of the IIS.

An svc file might look like this:

Language ="C#"
Debug ="true"
CodeBehind= "~/App_Code/MyService.cs"
Service = "MyService"

You can generate IIS hosted services with Visual studio.

Now that you have a brief overview over IIS we will explore the advantages and disadvantages:


Because IIS is widely used and a proven technology over time, the point that you can set it up easily from visual studio etc. makes it an easy to use approach to hosting your WCF service. It also manages the lifcycle of your service very well as we have seen.


One of the obvious disadvantages of IIS is that you can only use http bindings. Another point is that you have a full blown web server at hand, even though you simply want to host a service, that manages its threads and incoming calls with its own runtime. So with more overhead and more moving parts in general comes a higher possibilty for errors.
This is the reason Windows has another way to host your WCF services, the WAS.



So to avoid the overhead of a web server the Windows Activation Service (WAS) as a pure hosting engine exists. It uses the same process model as the IIS and also manages the lifecycle similarly to the IIS. With the first incoming client request the hosted application is sprung up and can serve the client requests.

Simply put WAS generalizes the IIS process model by removing the http dependency. This allows WCF services hosted in WAS to use any transport protocol.

A WAS can host several applications in one instance, groups them together into so called sites and can address each individually by a given URI constituted of the site and the relative uri of the application. Because WAS is a generalization of IIS it provides more robust, manageable and resource efficient hosting.

For more information on WAS see the following:
WAS Hosting


WAS is lightweight in relation to IIS and allows you to use any WCF transport scheme.


Because the WAS runtime is another moving part you do not have full control over you might want to avoid it. Else it is a very good tool to use for WCF hosting, if you strive for automated hosting.

Self- hosting

The third possible approach is to set up your own process to host your WCF service. This comes with the need to manage the lifecycle and that your process has to run, before any client request can be served.

The good thing is you can use any Windows process, like a console application, a WPF or Windows Forms process or any other Windows specific process.

To allow client requests in, you obviously need to set up the process, and your service needs to be controlled with the ServiceHost class. This ServiceHost needs to be instantiated and you need to call the Open() method on this instance. If you want to shutdown your Service you should call Close().

This is required for the WCF runtime to determine how the service needs to be constructed.
See ServiceHost:

public class ServiceHost : ServiceHostBase
public ServiceHost(Type serviceType, params Uri[] baseAddresses); 
public ServiceHost(object singletonInstance, params Uri[] baseAddresses); 
protected ServiceHost();
public object SingletonInstance { get; }
public ServiceEndpoint AddServiceEndpoint(Type implementedContract, Binding binding, string address); 
public ServiceEndpoint AddServiceEndpoint(Type implementedContract, Binding binding, string address, Uri listenUri); 
public ServiceEndpoint AddServiceEndpoint(Type implementedContract, Binding binding, Uri address, Uri listenUri); 
protected override void ApplyConfiguration(); 
protected override ServiceDescription CreateDescription(out IDictionary<string, ContractDescription> implementedContracts); 
protected void InitializeDescription(object singletonInstance, UriSchemeKeyedCollection baseAddresses); 
protected void InitializeDescription(Type serviceType, UriSchemeKeyedCollection baseAddresses); 
protected override void OnClosed();

The ServiceHost needs to be supplied with your service contract and can be supplied some default base Addresses. As you might remember you need to tell WCF where to find your service with the notion of Endpoints. This can be done with servicehost.AddServiceEndpoint method or in the app.config file. This method needs the Type of your implemented service contract. (see also set up a client)

For each of your service contracts you need a new servicehost, so it amounts to a one to one relationship between contract and servicehost.

As mentioned above the Open() method allows calls from clients in, and the Close() method lets all ongoing client requests gracefully exit. This means calls in process are not interrupted until the CloseTimeout is reached. The CloseTimeout will default to 10s for graceful exit, and else aborts all threads.

When you set up the ServiceHost instance it loads the WCF runtime with workerthreads to monitor incoming requests.

Advanced Hosting with ICommunicationObject

The ServiceHost implements the ICommunicationObject interface, which is defined as follows:

public interface ICommunicationObject
CommunicationState State { get; }
event EventHandler Opening;
event EventHandler Faulted;
event EventHandler Closing;
event EventHandler Closed state;
event EventHandler Opened;
void Abort();
IAsyncResult BeginClose(TimeSpan timeout, AsyncCallback callback, object state);
IAsyncResult BeginClose(AsyncCallback callback, object state);
IAsyncResult BeginOpen(TimeSpan timeout, AsyncCallback callback, object state);
IAsyncResult BeginOpen(AsyncCallback callback, object state);
void Close(TimeSpan timeout);
void Close();
void EndClose(IAsyncResult result); 
void EndOpen(IAsyncResult result); 
void Open(TimeSpan timeout); 
void Open();

This allows for several different modes of interaction. Firstly you can subscribe to different events during the process of handling incoming client requests and events for handling the communication.

Another use of this is to use asynchronous invocation patterns (APM -asynchronous programming model) for oppenening of the Host. The methods to use here are BeginOpen/BeginClose and EndOpen/EndClose.

It also allows to call Abort() for a non graceful exit of all active client requests (as with Close() and a CloseTimeout of TimeSpan.Zero).


Self- hosting can use any windows process for your WCF service, it also allows you to use every possible WCF transport protocol.
You also gain full access and control to the lifecycle of your service, as you can see in the section about self-hosting and ServiceHost.


With the need to set up your own process comes more complexity which can make the application more error prone.
Also you always need to set up the process before you can serve client requests opposed to the IIS and WAS solutions, which will do this automatically.

Lifecycle management issues have to be resolved by the devs, which again can lead to more complexity.

My 2 Cents

I personally most often choose to use self-hosting, because it lets me take full control over the lifecycle and I am able to use all supported bindings and transport schemes, especially TCP and IPC. This gives you as a developer of a WCF service the ability to use Callbacks, Transport Session and reliable messaging as well as sessionful services.

How to choose a host

If you want to host your service on the Internet, best use IIS or WAS to not concern yourself with the security concerns of Internet applications, in all other scenarios use Self-Hosting.



In this post we looked at the three methods to host your WCF service.

These are the hosting in an IIS web server, hosting the service in an WAS or use your own Windows process to self-host your service.

We also explored the advantages and disadvantages of each and looked at how to decide which hosting environment to use.

See for further information on Hosting

Categories: HowToWCF


Leave a Reply

Avatar placeholder