search

kiquenet / dropthings

Automatically exported from code.google.com/p/dropthings
0 stars 0 forks source link

adding additional port bindings in IIS breaks Webservice proxies,,, #247

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Add another port in IIS (i.e. 8500)using bindings
2.
3.

What is the expected output? What do you see instead?
Weproxies stop working.

What version of the product are you using? On what operating system?
latest.

Please provide any additional information below.
I am doing some development at home and trying to get around my ISP blocking 
port 80, so i thought i would let my associates see the portal coming in on 
port 8500. That seems to break the Webservice Proxies.

Omar, i'm sure it's something that i must put in web.config but i'm not sure 
what it is. Can you help me?

Original issue reported on code.google.com by venusian...@gmail.com on 29 Jul 2012 at 7:07

GoogleCodeExporter commented 8 years ago 
i did try changing all of my service nodes in web.config to include port 8500 
but the webservice proxies still do not like it.

Original comment by venusian...@gmail.com on 29 Jul 2012 at 8:52

GoogleCodeExporter commented 8 years ago 
You most likely have to use the <baseAddress> in WCF bindings.

Original comment by omaralzabir@gmail.com on 29 Jul 2012 at 9:09

GoogleCodeExporter commented 8 years ago 
            <add baseAddress="http://localhost:8500/dropthings" />

doesn't work.

I entered that for each of the 3 baseAddresses plus the webroot key.

Are you saying that it should work? Or, am i not entering them in the right 
place?

Watching any of the Olympics out there?

Original comment by venusian...@gmail.com on 29 Jul 2012 at 11:22

GoogleCodeExporter commented 8 years ago 
I remember now that I had the same problem and I ended up creating a new 
subdomain mapped to a new website in IIS to host the services. I created 
another website, pointing to the same code folder.

Original comment by omaralzabir@gmail.com on 30 Jul 2012 at 1:00

GoogleCodeExporter commented 8 years ago 
Ok, i tried that. Changed all the baseAddresses to reflect the virtual 
directory name that i'm using along with the port number (8105).

Still getting the same error (500), again, from the alternate port usage.

Original comment by venusian...@gmail.com on 30 Jul 2012 at 3:18

GoogleCodeExporter commented 8 years ago 
Still playing around with it and pointing to the same code with a virtual 
directory doesn't seem to change things.

Somewhere must be hardwired to only use port 80?

Original comment by venusian...@gmail.com on 30 Jul 2012 at 3:46

GoogleCodeExporter commented 8 years ago 
Virtual Directory won't work. You need a new top level website mapped to a new 
subdomain.

Original comment by omaralzabir@gmail.com on 30 Jul 2012 at 3:54

GoogleCodeExporter commented 8 years ago 
Just noticed, if your ISP is blocking port 80, then can't you just remove the 
port 80 (default) binding and have only the 8500 binding on IIS?

Original comment by omaralzabir@gmail.com on 30 Jul 2012 at 3:55

GoogleCodeExporter commented 8 years ago 
wow, that worked!

i do have other web projects, like dotnetnuke sites, that now won't work until 
i assign them all port 8105 aliases (that run on that same box).

good thinking, Omar. I can at least proceed with this for now.

Original comment by venusian...@gmail.com on 30 Jul 2012 at 3:59

GoogleCodeExporter commented 8 years ago 
wonder why additional bindings throws it off?

Original comment by venusian...@gmail.com on 30 Jul 2012 at 4:00

GoogleCodeExporter commented 8 years ago 
WCF limitation

Original comment by omaralzabir@gmail.com on 31 Jul 2012 at 10:07