What a Host Actually Provides
A WCF service class by itself is just a .NET object; it needs a host process to instantiate a ServiceHost, open its configured endpoints, and keep a listener running so incoming messages can be dispatched to the right operation. The host is responsible for the service's lifetime: starting it, managing instancing (per-call, per-session, or singleton), routing faults, and shutting it down cleanly. WCF supports several hosting environments, and the same ServiceContract implementation can typically run unmodified in any of them, since hosting is orthogonal to the contract.
Cricket analogy: A ServiceHost is like the BCCI providing a stadium and ground staff for a match: the players (service operations) don't change, but someone still has to open the gates, manage the pitch, and keep the scoreboard running.
Self-Hosting with ServiceHost
The simplest hosting model is self-hosting: creating a System.ServiceModel.ServiceHost instance directly inside any managed process — a console app, WPF app, or Windows Service — and calling Open() to start listening. Self-hosting gives full programmatic control over the host's lifetime and is common for Windows Services running netTcpBinding endpoints, but it makes the developer responsible for process recycling, crash recovery, and startup-on-boot, none of which come free the way they do under IIS.
Cricket analogy: Self-hosting is like a local club organizing its own weekend match on a rented ground: you handle the umpires, the scoreboard, and cleanup yourself, unlike a BCCI-run international fixture with dedicated staff.
using System;
using System.ServiceModel;
namespace OrderService
{
class Program
{
static void Main()
{
using (ServiceHost host = new ServiceHost(typeof(OrderProcessor)))
{
host.Open();
Console.WriteLine("OrderProcessor is running. Endpoints:");
foreach (var ep in host.Description.Endpoints)
{
Console.WriteLine($" {ep.Address}");
}
Console.WriteLine("Press ENTER to stop the service.");
Console.ReadLine();
host.Close();
}
}
}
}A ServiceHost must be disposed properly to avoid leaked listeners and file/port locks. Wrapping it in a using block calls Close() on normal exit, but if an unhandled exception occurs, prefer explicit try/catch around Open() and calling Abort() instead of Close() in the catch block, since Close() can itself throw if the host is in a faulted state.
IIS and WAS Hosting
For HTTP-based bindings, hosting inside IIS (or Windows Process Activation Service, WAS, for non-HTTP bindings like netTcpBinding) is usually preferred in production because it provides process recycling, idle shutdown, application pool isolation, and integration with IIS's existing management, logging, and SSL certificate tooling. IIS-hosted services use a .svc file that references the service class, or, with file-less activation, are configured entirely through web.config and the ServiceHostFactory, removing the need to manage a ServiceHost lifecycle by hand.
Cricket analogy: IIS hosting is like playing at a BCCI-certified international stadium with groundstaff, medical teams, and a maintenance schedule already in place, versus self-hosting's rented local ground with none of that support.
IIS hosting only supports the http/https-based transports natively unless WAS activation is explicitly enabled for TCP, named pipe, or MSMQ bindings. Attempting to host a netTcpBinding endpoint under plain IIS without enabling the Windows Communication Foundation Non-HTTP Activation feature and the net.tcp binding on the site will fail with an activation error at startup.
- A host manages the ServiceHost lifecycle: opening listeners, instancing, and shutdown.
- Self-hosting gives full programmatic control but requires manual process recovery and startup management.
- IIS/WAS hosting provides process recycling, isolation, and management tooling out of the box.
- IIS natively serves HTTP-based bindings; non-HTTP bindings need WAS activation enabled explicitly.
- A ServiceHost should be disposed carefully, preferring Abort() over Close() after a faulted state.
- The same ServiceContract implementation can run under any hosting model without code changes.
Practice what you learned
1. What is the primary responsibility of a WCF host?
2. Which of the following is a disadvantage of self-hosting compared to IIS hosting?
3. What must be enabled to host a netTcpBinding endpoint under IIS?
4. Why is Abort() sometimes preferred over Close() when handling a faulted ServiceHost?
5. Does the WCF service implementation class need to change depending on the hosting model chosen?
Was this page helpful?
You May Also Like
Self-Hosting vs IIS Hosting
A direct comparison of running WCF services in your own process versus letting IIS manage the process lifecycle.
WCF Bindings Explained
A tour of WCF's built-in bindings and how each one shapes the transport, encoding, and security of a service contract.
Endpoints and Behaviors
How WCF endpoints expose service operations and how behaviors attach cross-cutting runtime policies to services, endpoints, and operations.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics