WCF service startup error "This collection already contains an address with scheme http"

Question

I built a web application containing a WCF service contract and a Silverlight control which makes calls to that WCF service. On my development and test servers it works great.

When I deploy to our live server and run the application I get an exception of type System.ServiceModel.ServiceActivationException which states that the service can not be activated due to an exception during compilation. The exception is:

This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.

I read that this exception may be thrown if the web site has more than one host header, which is true on our live server. Apparently WCF services hosted in IIS can have only one base address. How can I get around this issue?

Answer 1

Summary,

Code solution: Here

Configuration solutions: Here

With the help of Mike Chaliy, I found some solutions on how to do this through code. Because this issue is going to affect pretty much all projects we deploy to a live environment I held out for a purely configuration solution. I eventually found one which details how to do it in .net 3.0 and .net 3.5.

Taken from the site, below is an example of how to alter your applications web config:

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

In the above example, net.tcp://payroll.myorg.com:8000 and http://shipping.myorg.com:9000 are the only base addresses, for their respective schemes, which will be allowed to be passed through. The baseAddressPrefixFilter does not support any wildcards .

The baseAddresses supplied by IIS may have addresses bound to other schemes not present in baseAddressPrefixFilter list. These addresses will not be filtered out.

Dns solution (untested): I think that if you created a new dns entry specific to your web application, added a new web site, and gave it a single host header matching the dns entry, you would mitigate this issue altogether, and would not have to write custom code or add prefixes to your web.config file.