Geeks With Blogs
The Unstable Mind of a .Net Developer


Recently, I began work on building WCF services for a Silverlight application that will be hosted in Azure.  While I cannot discuss some of the details of the application, I can definitely talk about some of the gotchas I encountered.


One of the things that all developers writing WCF services for Silverlight will encounter is the dreaded cross domain access exception.  In general, this is the means by which Silverlight attempts to guard against cross site forgery and other security vulnerabilities.  There are several posts out there that provide the solution to this problem, but without a lot of detail.  Basically, you have to install a clientaccesspolicy.xml file in the primary Azure Role that hosts your WCF services.  The format of that file is this:

<?xml version="1.0" encoding="utf-8" ?> 
      <allow-from http-request-headers="SOAPAction">
        <domain uri="*"/>
         <resource path="/" include-subpaths="true"/>

Great!  But what does it all mean?  Fortunately, Microsoft has the details here (  Basically, the important element is the <domain uri=””/>.  This defines which domains have access to the WCF services.  If you want only your Silverlight applications host on your network to have access, simply replace the * with


Another problem I encountered was trust.  It just so happens that my Silverlight control hosted by Azure was attempting to access the Lync client API.  Because of this, I had to put the url of my Azure application in my IE trusted sites list.  This would hold true for any application that attempted to initiate or access APIs hosted on the client.


Lastly, when I initially developed the Azure solution, I defined multiple web roles: the Silverlight application, a base web site with reporting and the WCF services.  However, this presented a problem in that when hosting multiple roles, Azure assigns them unique endpoints and therefore unique ports, the first on port 80, second port 81, and so on.  Working remotely, this had no impact on my development or access in the least.  However, when we turned it on for employees on the corporate network, traffic on ports 81 and 82 was blocked.

So, rather than expose the additional roles as Azure roles, I added them as VirtualApplications to the primary role with unique uris.  This is accomplished by modifying the ServiceDefinition.csdef file in the Azure project and adding <VirtualApplication /> elements to the <Site /> element.  In doing so, additional roles are accessed as subsites on the primary url all using port 80.


<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="LyncingAzure" xmlns="">
  <WebRole name="LyncingAzure.Main" vmsize="Small">
      <Site name="Web">
        <VirtualApplication name="svc" physicalDirectory="F:\StlDayOfDotNet\2012\LyncingAzure\LyncingAzure.WCF\" />
        <VirtualApplication name="sl" physicalDirectory="F:\StlDayOfDotNet\2012\LyncingAzure\LyncingAzure.SL.Web\" />
          <Binding name="Endpoint1" endpointName="Endpoint1" />
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />

In the example above, my WCF services can be accessed @ :80/svc">http://<primaryurl>:80/svc and my Silverlight application @ :80/sl">http://<primaryurl>:80/sl.


And, now, my application works perfectly with both my Silverlight and WCF services hosted in the cloud with an (almost) zero-touch installation on the client.


Ralph Wheaton
Microsoft Certified Technology Specialist
Microsoft Certified Professional Developer
Microsoft VTS-P BizTalk, .Net

Posted on Monday, August 6, 2012 12:01 PM Silverlight , WCF , Azure | Back to top

Comments on this post: Accessing WCF Services in the Cloud

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Ralph Wheaton | Powered by: