Hosting cross-domain Silverlight applications (XAP)

In the Silverlight world, there are two types of “cross-domain” things that may leave some banging their head against a wall for a while.  The first involves making network-based calls (WebClient, HttpWebRequest, etc) to services hosted on a domain other than the one that is the site of origin for the XAP.  This is solved by ensuring the service provider enables a clientaccesspolicy.xml file for their service.  More information here: Cross Domain Policy Files with Silverlight.

NOTE: “site of origin” is a term you might see a lot with regard to Silverlight.  This refers to the URI domain of the Silverlight XAP file.  For example: http://apps.mysite.com/sources/coolapp.xap might be a URI that you have for an app.  The site of origin in this is apps.mysite.com (more specifically it is actually the entire URI usually when people refer to this term).  This might help when you read things about cross-domain issues.

The second issues is one of hosting Silverlight applications (XAPs) on your site that are from a different domain.  What I mean here is that your site (www.coolwebapp.com) has an <object> tag for Silverlight plugin that has the Source parameter set to apps.anothersite.com/foo.xap.  This is essentially the cross-domain hosting situation.  What happens in this situation is that the plugin loads but the app does not, presenting in just a big blank space where the app should be.

A recent head-banger sent me a note and I sent him my items to check on how to solve this.  I thought I’d share.  When I see issues with this, I normally tell people to check for one (or more) of three things:

HTML Access

If the Silverlight application is doing anything to work with the HTML DOM of your hosting page, this is the first place to look.  Don’t know if this is happening?  If the Silverlight application uses System.Windows.Browser anywhere it likely does.  By default the tools and templates from Visual Studio generate the bar minimum <object> tag.  There is one property of the plugin, EnableHtmlAccess, that is set (essentially) to true for same-domain applications.  However, for cross-domain applications, you will need to opt-in for this adding this parameter to the <object> tag:

   1: <object data="data:application/x-silverlight-2," type="application/x-silverlight-2">

   2:   <param name="source" value="http://apps.somesite.com/foo.xap"/>

   3:   ...

   4:   ...

   5:   <param name="enableHtmlAccess" value="true" />

   6: </object>

By doing this, you are granting the XAP access to the HTML DOM of the hosting page.  Don’t say I didn’t warn you.

XAP MIME type

When the plugin loads a XAP from another domain, it checks what the MIME type is.  If it is not a valid Silverlight type, it won’t load the app.  This is a security mitigation.

If you are loading a cross-domain XAP, make sure the site delivering the XAP is delivering it with the appropriate MIME type: application/x-silverlight-app.  By default this is set in IIS7/Windows 2008, but not in IIS6/Windows 2003.  You can put this on the server level or the application level…wherever you feel comfortable, just as long as it is delivering it with the XAP. 

Obviously on non-Windows servers, this will not be set at all regardless of the version.  If you are getting a XAP from a Linux/Apache server for instance, the server administrator will want to add the type.  This is simple and you can do it at the global level in the mime.types file.  Or on a per-site basis you can do it by editing the .htaccess (or creating one) in the directory level that will serve the XAP and add:

   1: AddType application/x-silverlight-app xap

If you are using a CDN like Azure or Amazon S3 or something else and they don’t have the type associated, you will need to be creative.  Most CDNs enable you to set the MIME type (or Content-Type) on the file during upload.  For Azure, Silverlight should already be there.  For something like S3, tools like CloudBerry Explorer enable this feature for you (and actually already have a list of types built-in to their tool).

This situation (identifying the MIME type) can be quickly tested using a tool like Fiddler to see what the response and Content-Type are being delivered.  Fiddler is an indispensable tool…go get it, it’s free.

ExternalCallersFromCrossDomain

This is the black hole property right here.  This one is probably a last resort for most.  This property, in the Deployment node of your AppManifest.xaml file controls Javascript and HTML DOM access to scriptable objects defined in the XAP.  Like EnableHtmlAccess, for same-domain situations the setting is irrelevant, but in cross-domain hosted XAPs, the default is the NoAccess option.

To enable this you’ll need to manually edit the AppManifest.xaml file to add the ExternalCallersFromCrossDomain attribute.  There are two properties: NoAccess (default) and ScriptableOnly.  You’d want to *add* the attribute and set it to ScriptOnly.

   1: <Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" 

   2:             ExternalCallersFromCrossDomain="CrossDomainAccess" .../>

REMEMBER: This is is only if you need to.  Read the documentation to see if this applies to your scenario.

Summary

Sometimes debugging this stuff can be tricky. Having the tools and knowledge makes this easier to track down. Not all situations involve multiple of the above and if none of them fix it, then you might have another issue. Hopefully this helps provide some places to look.