Two Fundamentally Different Ownership Models
The core distinction between self-hosting and IIS hosting is who owns the process lifecycle. In self-hosting, your own code calls new ServiceHost(...) and Open(), meaning your application is the process, and it stays alive exactly as long as your code keeps running. In IIS hosting, the worker process (w3wp.exe) is owned and managed by IIS itself: IIS decides when to start it (on first request, by default), when to recycle it (memory thresholds, scheduled intervals, or configuration changes), and when to shut it down (idle timeout). Your service code becomes a passenger inside IIS's process management rather than the driver of it.
Cricket analogy: Self-hosting is like a franchise owner personally managing every match-day decision for their IPL team, while IIS hosting is like the BCCI centrally scheduling, staffing, and overseeing every match regardless of what the franchise wants.
When Self-Hosting Wins
Self-hosting is the right call when you need non-HTTP bindings without WAS configuration overhead, when the service must run as a long-lived background process independent of any web request (for example, a Windows Service polling a queue and pushing results over netTcpBinding), or when you need tight programmatic control over the exact moment the host opens and closes, such as coordinating startup with other in-process components. It's also common in unit and integration testing, where spinning up a lightweight in-memory ServiceHost avoids the overhead of a full IIS deployment.
Cricket analogy: Self-hosting for a background polling service is like a groundsman who tends the pitch on his own schedule around the clock, not waiting for a match to be scheduled before doing his job.
When IIS Hosting Wins
IIS hosting wins for request/response-style services exposed over HTTP, especially when they share infrastructure with existing ASP.NET or ASP.NET Core applications, need SSL certificate management already handled at the IIS level, or benefit from IIS's built-in process recycling to guard against memory leaks in long-running services. It also fits organizations with existing operational tooling (monitoring, log shipping, deployment pipelines) built around IIS-hosted applications, since a WCF service under IIS looks and behaves like any other IIS site to that tooling.
Cricket analogy: IIS hosting for HTTP-facing services is like playing in a BCCI-run stadium already wired for TV broadcast and ticketing systems, letting you plug straight into existing infrastructure instead of building your own.
<!-- OrderProcessor.svc — file-based activation under IIS -->
<%@ ServiceHost Language="C#"
Service="OrderService.OrderProcessor"
CodeBehind="OrderProcessor.svc.cs" %>
<!-- web.config excerpt -->
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"
multipleSiteBindingsEnabled="true" />
<services>
<service name="OrderService.OrderProcessor">
<endpoint address="" binding="wsHttpBinding"
contract="OrderService.IOrderProcessor" />
</service>
</services>
</system.serviceModel>IIS hosting activates a WCF service lazily — the worker process only starts on the first incoming request, not when the application pool starts (unless you configure Always On / autoStart preload). This means the very first call after a recycle or server reboot will experience a noticeable cold-start delay while assemblies load and the ServiceHost initializes.
A WCF service that maintains significant in-memory state (e.g., a long-lived singleton InstanceContextMode with cached data) is a poor fit for IIS hosting, because IIS's periodic process recycling will silently wipe that state, causing intermittent, hard-to-diagnose data loss unless the recycling schedule is disabled or the state is externalized.
- Self-hosting means your code owns the process lifecycle; IIS hosting means IIS owns it.
- Self-hosting suits long-lived background services and non-HTTP bindings without WAS setup.
- IIS hosting suits HTTP request/response services that benefit from existing operational tooling.
- IIS activates lazily on first request unless preload/Always On is explicitly configured.
- IIS's automatic process recycling can silently destroy in-memory singleton state.
- Both models can host the exact same ServiceContract implementation without code changes.
- The choice is primarily an operations and infrastructure decision, not a functional one.
Practice what you learned
1. Who controls the process lifecycle in a self-hosted WCF service?
2. What triggers a WCF service's worker process to start by default under IIS?
3. Why is IIS hosting risky for a singleton service that caches significant in-memory state?
4. Which scenario most naturally favors self-hosting over IIS hosting?
5. What must the service implementation class do differently to run under IIS hosting instead of self-hosting?
Was this page helpful?
You May Also Like
Hosting WCF Services
How WCF services get activated and run, from self-hosted console applications to IIS and Windows Activation Services.
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.
WCF Configuration Basics
How WCF services are wired together through web.config/app.config, and the essential Address-Binding-Contract structure behind every endpoint.
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