I had a little hickup today as I was playing around exploring Web services and Windows Azure. After scanning the Internet, I’m now convinced that most people out there working with Azure are hosting Web apps up there, not Web services, based on the amount of articles I found (unless of course people doing services just aren’t talking about it because it’s just soooo easy :)). Perhaps it was just my search terms, or maybe that’s what most people start with, but I found this interesting and thought I’d put together a post for anyone trying to get started deploying a WCF service to Windows Azure. I’m sure there’s some services-centric, probably SOA-ish folks out there wondering how to do this…
I put together a WCF service, and then deployed it:
- Locally (using the VS.NET dev Web server)
- Locally (use the Windows Azure development fabric)
- Remotely (to Windows Azure).
In this post I’ll go through the steps I followed. To get started, I:
- Created a Cloud service project
- I added a WCF service (note that I changed to basicHttp binding)
- I wrote a little code, ran the project locally, using the development Web server, and it worked no problemo
- I created a test client based on the WSDL exposed above
- I set my cloud service project as the startup project, and in Visual Studio, ran it.
The Azure SDK adds some Visual Studio templates, you get this:
In Visual Studio, my finished solution looks like this:
SIDEBAR: so why the heck is Brian using “Contoso”? More later, but this service is part of a greater whole which I will be blogging about.
For those of you who have not worked with Azure yet, one of the cool features you get is a “development fabric” that basically gets you a local copy of Windows Azure, including storage. Having spent as much time in airplanes as I have in the past year, this is really appealing. When a cloud service project is the startup project, running the solution will launch the development fabric. The UI for it looks like this:
Next, I repointed my test client to point at the address shown above. However, it failed. I got a 405 error, “method not allowed”. Turns out that the cause of this was that IIS7 did not have a handler mapping to SVC files, so didn’t know what to do with them. To fix this, I ran “ServiceModelReg -i” in the “c:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation” folder. Perhaps it was an installation sequencing issue that led to me not having WCF registered in IIS, or, maybe this is something you just have to do.
After I ran it, my handler mappings looked like this:
After that, I was able to call the service in my local Windows Azure development fabric. Cool!
Next up, how to deploy this to the cloud? You can do this using the CSPack command line utility, but for quick dev there’s an easier way. In Visual Studio, right-click the cloud project and choose “publish” from the context menu:
Now, you might expect choosing “publish” on a cloud service project would do something like, ummm… perhaps “publish the service”. Well, it doesn’t. What it does is actually prepare it for you to publish it in another step, it creates the configuration files you’ll need for that step. It also opens a browser that navigates to the Azure portal, as well as opening a Windows Explorer in the “publish” folder where it wrote out the two config files. You then use the portal to upload the files:
After you upload and start it looks like this in the portal UI:
And, that’s about all it takes. Clicking on the arrows in the middle swap out the “staging” and “production” instances of the deployed apps, which really is nothing more than a change at the load balancer level.
A year from now, it would probably just take a credit card number for this Web service to scale to millions of calls per hour. The future is closer than it appears I think, these are exciting times. Go forth and learn!