Archive for the ‘ WCF ’ Category

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.

Service Constructor

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 🙂


SVCUTIL and ServiceContracts

Shared ServiceContract Library

I had what I thought was a simple plan, create a server side (WCF) sln and a client side sln then from both of them reference the same BusinessObject (Biz) library and ServiceContract library.

What I wanted to do was use svcutil.exe to generate the client side implementation of the contract for me, so when any of the service contracts changed all I had to do was run a batch file which basically ran svcutil.

The Problem

So when you do a ‘right click, add service reference’, tick the box to re-use the Biz and ServiceContract libraries, what happens is the Biz objects are not generated (good, that was expected) but the contracts ARE still generated (am I missing a simple check box somewhere??).

I don’t want the contracts to be generated as it means I now have two versions of the same contract.

If you use svcutil.exe to generated the metadata and then the proxy code, by providing a few of the right switches you get the same result as ‘add service reference’. Ok good, now that I’m using the cmd line utility I will now have the power to tailor the generated code to my exact measures….not quite. Unless I’m missing somethings obvious (which is likely I’ll admit) there is not any switch to tell svcutil to NOT generate the ServiceContracts. Yes I am using the /r: switch to provide the assembly that contains the contracts…

So I’m thinking, unless you are willing to accept and allow there to be two versions of your service contract (which actually is very common, anyone using VS right click, ‘add service reference’ will have this setup…thus the need to regularly update service reference) then really it is not possible to use svcutil.exe.

The Solution

Well I hope to come back and update this in the near future with the approach we end up choosing. For now though, this post looks like a good ‘leg up’ and is certainly worth a read. I’ll be exploring that idea and a few others and report back….

Why Bother?

Why go through the hassle, why not just use the old, ‘right click add service reference’? Well, every WCF ‘expert’ I know of says that approach is the beginners way of creating your WCF service proxies, either in their blogs or .net rocks episodes etc. It is certainly very quick but the generated code is overly verbose and as it is generated code you have less control over the way it works.

Share your interfaces
Extreme WCF

WCF the manual way…The RIGHT way
WCF Standards from iDesign