My past experience with WCF services has followed a slightly unusual path. For a variety of reasons, most of the services I've written have consisted of an interface and an implementation. Pretty straight-forward thus far. However, where it gets a little unusual is in the hosting mechanism. We're using Windows services to host of WCF services. This works out well for us, since these services live on intranets, and aren't publicly exposed.
When looking at Azure, services are a little different. It's probably more akin to creating IIS-hosted WCF services. When you right-click on the web role and add a WCF service, it adds this wacky .svc file -- something I've never run into using Windows service hosting.
As if that weren't enough of a change to wrap my addled brain around, there's a pretty big issue around adding a service reference. Specifically, Azure doesn't expose wsdl very well. Sure, you can hit http://myapp.cloudapp.net/myservice.svc and it will give you the standard web page that lets you know it's listening. But... what's wrong with this picture?
That's right... the Azure service tells you to get the WSDL to build your proxies from a URL that is somewhat "non-standard." In other words, you can't get to it.
Simple workaround: add a service reference against a local copy and change the URL to point to the cloud. Since Azure services can only listen on port 80 (for http) or port 443 (for https), there's no need to specify the port number.