This collection already contains an address with scheme http

Since the sandbox update, after working around my deployment issue, I get the following error. The code is the same as before the update (verified via revision control) with the exception of the work around for deployment.

I am wondering (with little expertise in the area) if this could have to do with multiple sandbox accounts being hosted on the same box. Since I don't have multiple http endpoints in my web.config, I wonder if it's the collective of mine and other peoples' applications contributing to this problem and maybe there is an IIS setting that can be employed? Again, I'm stabbing in the dark here.

I'm verifying the error by simply hitting my test service like this:
http://user482.netfx4lab.discountasp.net/chupacabra.svc

This collection already contains an address with scheme http. There can be at most one address per scheme in this collection. If your service is being hosted in IIS you can fix the problem by setting 'system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled' to true or specifying 'system.serviceModel/serviceHostingEnvironment/baseAddressPrefixFilters'.
Parameter name: item

As usual, any help, ideas, or input from anyone having such an issue would be welcomed.
-Jonathan

 

I've seen it in the DASP v3.5 production environment but not the sandbox however I suppose the cause could be the same. For me it was related to the production IIS7 being configured with multiple host headers.

I have solved it with the implementation of a custom factory however things have moved on a bit now and there are other solutions (baseAddressPrefixFilters perhaps) for this problem now. In fact I thought this issue had been completely addressed in .NET 4.0 where WCF multiple host header support was now an opt in rather than the default option as it was in previous versions.

Anyway, there is a very good detailed article about this specific issue from one of the Microsoft guys here: http://blogs.msdn.com/rampo/archive...-multiple-iis-binding-specified-per-site.aspx

HTH

 

Joe,

You are right on. Apparently, in BETA 2, it was automatically handled. For RC1, they changed it. You have to turn it on. This was easy enough; however, a new error then popped up that the URL had to be relative. This is in direct contrast to what the MS guy's blog says. He says it must be absolute. I set it to relative and now the service comes up but I cannot connect to it from my app for some reason.

Anyway, thanks...got me on the right track.
-Jonathan

 

Ok. Got it working. Thanks again, Joe.

Here's how I had to change the configuration to get it to work in my debug environment. Note the debug environment did not require this fix but, once the multipleSiteBindingsEnabled was set to true, it did exhibit all the restrictions required to get the full deal to work.

Added this line in system.serviceModel:
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
Then, things stopped working even in my test environment but the exceptions did explain what they wanted me to change albeit not entirely clearly. Once that was set, I had to change the service to use a relative listen URI.

BEFORE making changes, this is what I had:
<service name="WordFall.Web.Chupacabra">
<endpoint name="ChupaEndPoint" address="http://localhost:80/Chupacabra.svc" behaviorConfiguration="SilverlightFaultBehavior"
binding="basicHttpBinding" bindingConfiguration="" contract="WordFall.Web.IChupacabra" />

This is what I had to add to get it to work.
<service name="WordFall.Web.Chupacabra">
<endpoint name="ChupaEndPoint" listenUri="/" address="http://localhost/Chupacabra.svc" behaviorConfiguration="SilverlightFaultBehavior"
binding="basicHttpBinding" bindingConfiguration="" contract="WordFall.Web.IChupacabra" />

Hope this helps anyone that has the same issue. Sorry this post is a bit rushed but there's so many things I haven't been working since this has been broken I'm anxious to move on. Feel free to post if you need a clarification.
-Jonathan

 

Thanks for posting the follow-up.

 

Same issue since the RC upgrade, however in my regular account (not the sandbox)

I am having the same issue "This collection already contains an address with scheme http." since the RC upgrade however my issue is with my regular account ; not my sandbox account.

I was under the impression that only the sandbox (trial 4.0) was getting upgraded not the regular accounts which are still on 3.5 version.

I have been hosting my Web Service on my regular account (3.5) account for a few months now, I am following the exact same steps as I always have so am quite confident that its not anything I am missing.

I use to get this error the first time I was trying to deploy my WS, however I was able to solve that by writing my own hostFactory. That code hasnt changed however now things have stopped working.

Any help would be greatly appreciated.

 

That's correct.

Did you look in to what CrystalCMS said about host headers?

 

Thanks mjp. That worked !!!

I did go through CrystalCMS's suggestion again (carefully this time) and the solution works.

Thanks a lot, however I am still puzzled regarding the fact that I had to change my code for my v3.5 account which you confirmed was not touched. I hadn't made any major change to the code which has been running on your site since Nov 2009 and I always follow the same deployment steps. I will let you experts at DASP to dig into that.

In a way this is good as I no longer have to use the hostFactory mechanism and it saves me 3-4 steps everytime I deploy

For anyone else who comes across this issue on their regular account (v3.5 not the 4.0 sandbox) since the (2/15) RC here is how the issue was fixed:

1. Under <system.serviceModel> add:

<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="http://www.yourdomain_name.com"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>


2. Update only the address attr in the endpoint tag for 'basicHttpBinding' to look like :
<endpoint address="http://www.< -- Complete url to your svc file-->.svc" ...
...
</endpoint>

Remember only to fill the address attribute, everything else remains same.


If you have been using the hostFactory there is no need for that now so you may comment that out.

Hope this helps.