Introduction

The WCF startup error saying that the collection already contains an address with scheme http means the service host has been given duplicate HTTP base addresses. The message looks obscure at first, but the underlying problem is usually simple: two parts of the hosting configuration are both trying to define the same address family.

That is why the fix is usually in host setup, app.config, web.config, or IIS bindings rather than in the service implementation itself.

Where the Duplicate Address Comes From

WCF builds a service host from base addresses and endpoints. If more than one HTTP base address is added where only one should exist, host startup fails before your service can accept requests.

Common sources are:

• a base address added in code and again in config
• IIS bindings combined with manual HTTP base addresses in config
• copied endpoints that implicitly create conflicting address definitions
• environment-specific transforms that duplicate the same scheme

A minimal self-hosted example that can trigger the issue looks like this:

1using System;
2using System.ServiceModel;
3
4[ServiceContract]
5public interface IEchoService
6{
7    [OperationContract]
8    string Echo(string text);
9}
10
11public class EchoService : IEchoService
12{
13    public string Echo(string text) => text;
14}
15
16var base1 = new Uri("http://localhost:8000/EchoService");
17var base2 = new Uri("http://localhost:9000/EchoService");
18using var host = new ServiceHost(typeof(EchoService), base1, base2);
19host.Open();

If the host configuration expects one HTTP base address, this setup is enough to cause the error.

IIS-Hosted and Self-Hosted Services Behave Differently

The first debugging step is to identify the hosting model.

In self-hosted WCF, your code usually creates the ServiceHost and provides base addresses directly. In IIS-hosted WCF, IIS bindings already provide the address environment, so adding extra HTTP base addresses in config often creates duplication.

That difference matters because a config file that looks harmless in self-hosted code can break an IIS deployment immediately.

A Typical Configuration Mistake

This is a common pattern in config files copied between projects:

1<service name="MyNamespace.EchoService">
2  <host>
3    <baseAddresses>
4      <add baseAddress="http://localhost:8000/EchoService" />
5      <add baseAddress="http://localhost:9000/EchoService" />
6    </baseAddresses>
7  </host>
8  <endpoint address="" binding="basicHttpBinding" contract="MyNamespace.IEchoService" />
9</service>

If the service is IIS-hosted, remove manual HTTP base addresses and let IIS bindings define them. If the service is self-hosted, keep one clear HTTP base address source and avoid duplicating it in both code and config.

A Safe Repair Strategy

Use a narrow checklist instead of changing several things at once:

1. identify whether the service is IIS-hosted or self-hosted
2. inspect code for ServiceHost constructor base addresses
3. inspect config for <host><baseAddresses> entries
4. inspect IIS bindings if the service is web-hosted
5. keep exactly one source of truth for the HTTP base address

That usually resolves the error quickly and keeps the configuration easier to maintain.

Verifying the Fix

After removing duplicates, start with the smallest possible endpoint set. One base address and one endpoint are enough to prove the host opens correctly.

If the service then starts, add back additional endpoints one at a time. That approach is better than applying large configuration changes and guessing which one removed the conflict.

Common Pitfalls

• Defining base addresses in both code and configuration.
• Treating an IIS-hosted service as if it were self-hosted.
• Searching only endpoint definitions while ignoring the base-address collection.
• Leaving environment transforms that reintroduce the duplicate address in staging or production.
• Changing service contract code even though the failure occurs before request handling begins.

Summary

• This WCF error means duplicate HTTP base addresses were added to the host.
• The root cause is usually configuration overlap, not service logic.
• Check the hosting model first, because IIS-hosted and self-hosted services are configured differently.
• Keep one source of truth for HTTP base addresses.
• Verify the repair with the smallest working host configuration before adding complexity back.