Silverlight, WCF, WSDL, Proxy, LoadBalancer, IIS & Headaches

Ever ran into the problem, when talking via WCF to a service, all your service calls fail because the servicehost-address in the generated WSDL is wrong?  In that case, this post is for you! 🙂

Think of a network setup like this:

• you’ve got a Silverlight-app, speaking with a bunch of services through WCF, over https.
• however, your app doesn’t talk directly to your servicehost.  It talks to a proxy.  And that proxy forwards to an internal load balancer.  And that load balancer in turn forwards to different web servers containing the servicehost installations.

This is the setup I was dealing with @ a certain company.  The app worked correctly in dev & test, where no proxy/load balancer was used.  However, when rolling it out to the production environment, everything started to go horribly wrong… every service call failed.

After taking a look at the WSDL of one of the services, it seemed that the problem was related to the network setup: the address in the WSDL wasn’t the external address anymore, it was the address of (one of the) the internal web server(s) (yes, even behind the load balancer) where the servicehost was installed.  Needless to say, this was reason all the calls failed, seeing the internal address was off course inaccessible from outside.

Pretty annoying problem.  I started looking around a bit, and found out more people seemed to have this problem.  I’ve read various posts describing possible solutions with custom bindings (not that easy when using Silverlight, since not everything WCF-related is available), and the general sentiment portrayed in the posts seemed to be that this was a shortcoming of WCF.  Another post described a new setting in 3.5 SP1, baseAddressPrefixFilter, that was supposed to solve this problem. However, that didn’t do the trick. In the end, we could off course have opted to just write a custom factory – that would definitely solve this problem; but that just didn’t feel right – surely, there must be a better way to solve this problem? After all, the network setup described isn’t that uncommon in Enterprise scenarios.

After a lot of searching & trial and error, it was one of my collegues (our WCF specialist) who put me on the right track: he figured this wasn’t a WCF problem – after all, WCF gets it’s addresses from IIS bindings, so he thought the problem was IIS-related, not WCF-related. And after looking into this, turns out he was right! Using appcmd.exe, we set the bindings in IIS on our website behind the loadbalancer to bind to the external address we wanted to see in the WSDL. After doing this, when WCF gets to the load balancer, this last one knows through the bindings what address to return, and thus the generated WSDL contains the correct (external) address for service locations!

So, quick tip for everyone: if you’re using a network setup as described above, and you get a WSDL that contains the wrong hosts/service op locations, first have a look at your IIS configuration/bindings, before diving into (or blaming…) the lesser-known depths of WCF! 🙂