A colleague approached me to solve a Silverlight issue where a cross-domain web service call was generating a SecurityException. We checked that clientaccesspolicy.xml was in the correct place and should allow the call and then we ran Fiddler. What we noticed was that Silverlight was not even attempting the request for the clientaccesspolicy.xml file!
After some investigation and supposition, we eventually traced it down to an issue with Internet Security Zones. The Silverlight hosting page was being accessed through a fully qualified domain name and was in the Internet zone, while the service was being accessed via computer name and was in the Intranet zone. The solution was to setup a full DNS entry for the service and use that from our SL application, because then the service host was also in the Internet zone and so the call was allowed.
Now it definitely does make sense that an Internet site should not be able to make cross-domain calls into your Intranet (and kudos to the Silverlight team for taking security this seriously) but it can be a tricky problem to spot when it’s happening in your dev environment!