WCF in Azure – Lessons Learned
Recently I’ve been trying to get my WCF services working in Azure, this post shares some lessons learned. Some of these lessons will likely be obvious for those of you familiar with hosting WCF services in IIS, however I personally haven’t written web sites for about 5 years so even if my memory served me well (which often it doesn’t) things have changed somewhat.
WebRole vs WorkerRole
Probably one of the first questions you will run into is ‘which role do I choose to run my services in?’
WebRole – Choose this if you want your services hosted in IIS
WorkerRole – Choose this if you want to spin up your own ServiceHost instances.
Before trying to make my services work in Azure I was hosting them in a simple Console app and was therefore creating my own ServiceHost instances. So at first I tried getting my existing code working in a WorkerRole.
I could make it work in the local devfabric but I couldn’t make it work in the cloud, the worker role seemed to start ok but the endpoints were not being exposed publicly, or maybe they failed to be created?
I’m still not sure why because I changed tactics and changed my services run in IIS. The main reason for this is I figure running the services in IIS will be more robust and will provide better reporting.
My change of tactics brought on the next problem…
Getting WebRole Working with Service implementation in Different Project
My service implementation code was in it’s own separate project, the service contracts were in another project as well. All WCF in Azure examples I found had the service, the contract and .svc in the WebRole. I wanted to keep my existing structure and it turned out to be very easy to do.
All that was needed was to put some .svc files (one for each endpoint) into the WebRole project and voila, endpoints available in the devfabric and in the cloud.
Contents of the .svc files….
<%@ ServiceHost Language="C#" Debug="true" Service="ServiceNamespace.ServiceName" %>
Note that the .svc files must be in the root directory of the WebRole project as Azure does not have a concept of Virtual Directories.
I still need to more play time to understand how this works more clearly. However what I did find is that if when I changed the port from 80 to 81 my endpoints were no longer visible in the cloud (they were visible in the devfabric).
Cloud Cover – Channel 9
I’d say this is an invaluable resource, lots of useful Azure info for developers….
Making Azure Services Available to Silverlight Clients
This is another thing that turned out to be quite simple.
To make any WCF service available to an SL client you must have a crossdomain.xml file. Normally you need to put this file in the IIS root directory, the way to do this for Azure is to simply drop the file into the root directory of the WebRole project.
Easy! Though I’d suggest host the services in ‘non-azure’ IIS and get it all working before switching to Azure. The crossdomain.xml thingy can be tricky, I’ve posted about wrestling with crossdomain.xml before.
My web services were using an IoC container for various things and so the constructor of each service took a container. For an IIS hosted service you need to have a parameterless constructor so I had to make some semantic changes to the code to allow for this.
It took a bit of trial and error to get things working but overall I’d say most of the challenges I faced were more about my lack of knowledge rather than any real problems with Azure. I like it….and am looking forward to learning more