Skip to content

Opening Internal HTTP Endpoints on Azure Worker Roles

May 16, 2011

A great thing about WCF is that it makes creating web services really simple: define a class and mark the web service API functions with attributes, then fill in the implementation of these functions to access your data (or whatever your web service is serving), and the framework converts it into a working implementation that handles all the I/O and serialization.

The downside is that when something doesn’t work as it should, the reason is often so buried in obtuse configuration settings or other not-well-documented parts of .NET, that you end up spending hours on trial-and-error and/or searching the internet to figure out why. Forums, while sometimes helpful, tend to accumulate misinformation that may even lead to a wild goose chase. The more obscure the problem, the more inaccurate answers seem to be (forum contributors will attempt to sound authoritative while taking wild guesses, or more likely, suggesting solutions that worked for a different kind of problem that only on the surface seem similar).

If a blog actually addresses your problem that’s a good sign, because it’s more likely posting a real solution. That’s why, after wasting a half-day looking for a fix for a problem, being led astray by well-meaning but incorrect forum solutions, and ready to throw in the towel, I was super happy to finally hit upon this post. It turned up low in my search results, way below all the useless forum clutter, but it described my problem and the solution exactly.

My symptom: starting a WCF service on the HTTP endpoint in a Azure worker role ran fine on my development system, but failed to start when deployed to the cloud. The problem: when an Azure role sets up an internal endpoint, it reserves the port for your application using an “IP-bound Weak Wildcard” reservation. The solution: Your application must register for the port using the same type as the reservation, which happens to NOT be the default for WCF, meaning you must override the default port binding. Simple enough to do, but nowhere in any MSDN Azure documentation could I find mention of how ports were reserved. I’m lucky this blog spelled it out for me, so thanks blog! I link to it here to hopefully help other people find it.

In case that site ever goes down, here’s the important code snippet that adds the endpoint binding after creating the service host, as demonstrated on lines 3-4:

1
2
3
4
var uri = new Uri(string.Format("http://mysite/myservice.svc", address));
var host = new WebServiceHost(typeof(Service), uri);
var binding = new WebHttpBinding { HostNameComparisonMode = HostNameComparisonMode.Exact };
var ep = host.AddServiceEndpoint(typeof(IService), binding, "");
No comments yet

Leave a Reply

Your email address will not be published. Required fields are marked *