Comprehensive Analysis and Solutions for WCF Service Startup Error "This collection already contains an address with scheme http"

When deploying Windows Communication Foundation (WCF) services to production environments, developers often encounter the System.ServiceModel.ServiceActivationException with the error message "This collection already contains an address with scheme http. There can be at most one address per scheme in this collection." This issue stems from the base address limitation of WCF services hosted in Internet Information Services (IIS), particularly in scenarios where the server is configured with multiple host headers. Based on the best answer from technical communities, this article systematically analyzes the error cause and provides multiple solutions covering configuration, code, and infrastructure levels.

Error Root Cause and Background Analysis

When WCF services run in IIS, they rely on base addresses provided by IIS to establish service endpoints. By default, WCF is designed to support only one base address per scheme (e.g., http, https, net.tcp). When an IIS website binds to multiple host headers, such as supporting both example.com and www.example.com, IIS generates separate base addresses for each host header, causing WCF to detect multiple http scheme addresses during initialization and throw the aforementioned exception. This explains why services run smoothly on development or test servers (typically configured with a single host header) but fail after deployment to production.

Solution 1: Using the multipleSiteBindingsEnabled Configuration in .NET 4.0

For applications based on .NET Framework 4.0 or later, Microsoft introduced the multipleSiteBindingsEnabled property, allowing WCF services to accept multiple base addresses. This solution is implemented by simply modifying the Web.config file without additional code. Add the following configuration in the system.serviceModel section:

<system.serviceModel>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>

Once enabled, WCF will automatically handle all base addresses provided by IIS, eliminating address conflicts. This is suitable for most modern deployment scenarios but note that it only supports .NET 4.0 and above.

Solution 2: Filtering Addresses with baseAddressPrefixFilters in .NET 3.0/3.5

For earlier .NET versions (e.g., 3.0 or 3.5), the baseAddressPrefixFilters configuration can be used to explicitly specify allowed base address prefixes. This method filters the address list provided by IIS, ensuring only one address per scheme is retained. Below is an example Web.config configuration:

<system.serviceModel>
    <serviceHostingEnvironment>
        <baseAddressPrefixFilters>
            <add prefix="http://shipping.myorg.com:9000"/>
            <add prefix="net.tcp://payroll.myorg.com:8000"/>
        </baseAddressPrefixFilters>
    </serviceHostingEnvironment>
</system.serviceModel>

In this example, only addresses with prefixes matching http://shipping.myorg.com:9000 and net.tcp://payroll.myorg.com:8000 will be accepted by WCF, while others are ignored. Note that baseAddressPrefixFilters does not support wildcards; prefixes must be specified exactly, and only scheme types in the list are filtered.

Solution 3: Alternative Methods via DNS and IIS Configuration

Beyond code and configuration solutions, infrastructure adjustments can resolve this issue. For instance, create a dedicated DNS entry for the WCF service (e.g., wcf.example.com) and configure a new website in IIS bound solely to that single host header. This approach avoids WCF's address limitations without modifying application code or configuration files but requires server administrative privileges and DNS setup. Although this solution is less tested in technical communities, it offers a purely operational-level resolution suitable for legacy systems where code changes are not feasible.

Comprehensive Comparison and Best Practice Recommendations

Based on the error scenario and solution analysis, the following best practices are recommended: For new projects, prioritize the .NET 4.0 multipleSiteBindingsEnabled configuration due to its simplicity and automatic address management. For maintaining older .NET applications, baseAddressPrefixFilters provides flexible control but requires accurate prefix configuration. In complex or multi-tenant environments, combining DNS and IIS configuration may be more stable. Regardless of the chosen solution, thorough testing in production-like environments before deployment is essential to validate address filtering or binding effects.

In summary, WCF's base address limitation is a common pitfall in IIS hosting, but by understanding its mechanisms and applying the solutions discussed, developers can effectively avoid deployment errors and ensure service reliability in production. This article is refined from best answers on communities like Stack Overflow, aiming to provide practical and comprehensive technical guidance.