First time here?

You are looking at the most recent posts. You may also want to check out older archives. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS or email. Thank you for visiting!

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.


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.


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.


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.

This work is licensed under a Creative Commons Attribution By license.

6/11/2010 9:57 AM | # re: Hosting cross-domain Silverlight applications (XAP)
Thanks for sharing your knowledge.
Particualar For our case, it is not functional and I could not find why it is so difficult to host such an application with WCF Services,
should be as simple as a WINDOWSFORMS.
Of how remotely is called the application generates a different error.
1 - If called with the domain name: www.dominio.com/dirapp/Default.htlm
generates an error that gives no further explanation:
The remote server responds NotFound
2 - If called with the IP: http://IP/dirapp/Default.html then appears on a cross-domain.
the last tests I have done for these suggestions.
Could you help another route is to solve this issue.
Thanks in advance for your time and cooperation.
6/12/2010 9:19 AM | # Getting Started With Silverlight
Tim, thanks for your blogs on Silverlight. I'm not sure this is the place, but maybe you can direct me where best to go. The thing is this, most Silverlight blogs are creating a Silverlight application. But what if you want to start slowly. What if you have an existing ASP.NET web application and want to take one of the web forms and convert that to Silverlight, kind of like a test pilot.

For instance, at my job we have an administrative type of web site application that is used to view and modify many things in the back-end. For example, unlock a user's account, or set their password.

I was thinking of taking this application and slowly start modifying web forms in it to use Silverlight, allowing me to gradually learn Silverlight and also use it as a pilot project, proof-of-concept testing grounds.

I was taking a look at your "Getting Started With Silverlight Development" blog series, but you see it uses a Silverlight Navigation Application template. Would that work for what I want? In essence, initially I want to be able to navigate from an ASP.NET application to a Silverlight page, that will eventually replace the ASP.NET equivalent page.

Is this possible? If so, what approach do you suggest then?

Thanks in advance for any suggestions, and forgive me if this was not the right place to make such a request.
6/14/2010 1:28 AM | # re: Hosting cross-domain Silverlight applications (XAP)
Another really annoying problem with a cross-domain hosted app is the splash screen inability to react to the download progress of the .xap files.
Maybe you could explain this deeper in another post, because there's almost nothing existing on that subject.
6/28/2010 2:31 PM | # re: Hosting cross-domain Silverlight applications (XAP)
Further food for thought,
IE also seems to throw a 401 on ClientAccessPolicy.xml if you move networks and refresh a page that contains Silverlight.

I know you might not be the exact person to help resolve this, maybe you could bounce this off someone that might.

Thanks a ton if you can help! I know you're busy with your move.
-Craig Young
6/30/2010 3:19 PM | # re: Hosting cross-domain Silverlight applications (XAP)
Ok, I take it back. I've solved this. The blame goes to our Sharepoint MOSS 2007 Servers not doing the correct authentication. All is well now.
Apologies, for taking up your time.
7/16/2010 8:53 AM | # re: Hosting cross-domain Silverlight applications (XAP)

Thank you for your article which provides a complete method to solve the problem I'm facing: Including a Silverlight application in a HTML host page (dynamically built by an Ajax application created by using GWT in my case) and making the Javascript code interoperate with the API published by the Silverlight application.

The problem is that, it does not seem to solve my problem !!

My application works fine if the xap is loaded from the same server as the Ajax application but if this is not the case (the real production use case), it is impossible to obtain the "content" object that is supposed to be located in the hosted Silverlight plug-in.

I have tested all the possible values of the properties you explain in your article without any result (I also tried values or properties that are documented on some sites but not others such as ExternalCallersFromCrossDomain="FullAccess" or HtmlAccess="Enabled" instead of enableHtmlAccess).

My current configuration is the following:

* The IIS server that hosts the xap is configured to map the MIME type as follows:
xap --> application/x-silverlight-app

* The AppManifest.xaml of the xap contains the property ExternalCallersFromCrossDomain="ScriptableOnly".

* The <object> marker that is included in the HTML host page is:

<param name="autoUpgrade" value="true"/>
<param name="onError" value="onSilverlightError"/>
<param name="minRuntimeVersion" value="3.0.40624.0"/>
<param name="enableHtmlAccess" value="true"/>
<param name="source" value="http://<other-server-name>:<other-server-port>/ClientBin/app.xap"/>
<param name="Windowless" value="true"/>
<param name="background" value="white"/>

alt='Get Microsoft Silverlight'


With this, the xap is correctly loaded and the silverlight application works (it displays the data it has to) but impossible to make it interoperate with the DOM in a crossdomain scenario.

Do you have any idea of what could be the problem ? Thank you very much in advance for any orientation you can think about to solve this.

10/24/2010 8:25 PM | # re: Hosting cross-domain Silverlight applications (XAP)
Mother F-er -- this one *repeatedly* gets me:

"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."

It's because the ASP.NET Development Server (Cassini) built into Visual Studio doesn't freaking send this MIME type, and there's no way to configure it to do so!

This is never a problem in production, so I take it for granted, and the few seldom times I'm testing something with my local solution I waste hours banging my head against this.

Thanks for the refresher. =)
1/26/2011 1:58 PM | # re: Hosting cross-domain Silverlight applications (XAP)
William, I am having the same issue. I have enabled every property known to man and silverlight will still not allow me to call the exposed method with javascript in a cross domain scenario. Were you able to find a solution?
3/12/2011 7:24 AM | # re: Hosting cross-domain Silverlight applications (XAP)
Come of the best efforts by XAP developers and I think there is a great work being played. Thanks Google
3/31/2011 12:54 PM | # re: Hosting cross-domain Silverlight applications (XAP)
Thanks for the troubleshooting tips, it's really very useful. Software mrp
6/16/2011 1:01 AM | # re: Hosting cross-domain Silverlight applications (XAP)
Every sentence has a lot of importance. It is always informative,exclusive,impressive and unique one. I expect more from you. Your post are best. ---Mighael donahuue
8/30/2011 10:50 PM | # re: Hosting cross-domain Silverlight applications (XAP)
Hey, thanks heaps!
I'm not very experienced with SL dev, and I've been struggling for hours trying to work out what was wrong with our app at work, being hosted on one subdomain, and loaded from the other. MIMETYPE FAIL.

You've saved me. :D

9/1/2011 9:32 AM | # re: Hosting cross-domain Silverlight applications (XAP)
There is a regression bug from Silverlight 3 to Silverlight 4 and ExternalCallersFromCrossDomain = ScriptableOnly does not permit JavaScript to access the Silverlight controls public properties and methods.
9/18/2011 1:17 PM | # re: Hosting cross-domain Silverlight applications (XAP)
I was just trying to host the xap file in IIS and load it from a page in the VS develop server but it doesn't work. I have done everything that was described:
1. I have ensured that IIS returns the correct mime type for the xap file
2. I have added the ExternalCallersFromCrossDomain="ScriptableOnly" in the AppManifest.xml file
3. I have added the enableHtmlAccess parameter to the object in the html file

But nothing, I have checked and the xap file will not be downloaded! Images, scripts everything is downloaded from IIS but not the xap file!
This is really frustrating and there is no way to have some hints to find the problem and solve it! I begin to feel happy that microsoft decided to kill Silverlight!

10/8/2011 11:55 PM | # re: Hosting cross-domain Silverlight applications (XAP)
follow his work on his site because I am learning photography, I was searching some pictures online and found your site. Aluminum Wallet
11/1/2011 3:41 AM | # re: Hosting cross-domain Silverlight applications (XAP)
Thanx a lot...
8/18/2017 7:45 AM | # re: Hosting cross-domain Silverlight applications (XAP)
One feature of Silverlight submission deployment just caused me a significant quantity of pain – the safety rules leading where the Silverlight browser plug-in will and will not load code from and below what conditions. Not necessarily the things will work accordingly but as concerned with the Web Design Service usually not to delivered debugging stuff.

Please add 2 and 1 and type the answer here:


The opinions/content expressed on this blog are provided "ASIS" with no warranties and are my own personal opinions/content (unless otherwise noted) and do not represent my employer's view in any way.