Getting WCF services in the DevFabric to work

I must have encountered these problems a dozen times or more over recent months when working with customers, so I thought I ought to write it down. When porting a service to run in Azure, you typically start by targetting the DevFabric which essentially simulates your service behind a load balancer. However, there are some challenges in getting this to work. Here are the 3 key steps you need to take.

1. Install the HOTFIX for WCF services to work behind a load balancer. NB: There are 2 versions depending on your OS.

The hotfix causes WCF to generate the correct URI by using the “Host” HTTP header of the incoming metadata request. In this case, the “Host” header contains the load balancer address instead of the internal node address.

2. Add the following behaviour to your service model

<serviceBehaviors>
   <behavior name="<name>">
     <useRequestHeadersForMetadataAddress>
       <defaultPorts>
          <add scheme="http" port="81" />
          <add scheme="https" port="444" />
        </defaultPorts>
      </useRequestHeadersForMetadataAddress>
   </behavior>
</serviceBehaviors>

If a URI inside the WSDL document has a different scheme than the scheme of the “Host” header URI, for example, if a request for metadata comes over HTTPS but the metadata contains HTTP URIs, the hotfix will need the port number for that different scheme. The port number can be specified per scheme in the <defaultPorts> section.

3. Decorate your service class with the following attribute:

[ServiceBehavior(AddressFilterMode=AddressFilterMode.Any)]

By default, WCF ensures that the To of each Message matches the intended address. This essentially turns off address filtering, so that the service doesn’t care anymore.

I’m sure there are other tweeks you’ll need to make, but these fixes are the most common ones I’ve come across.

Advertisements