From the public service announcement department, this is an issue I recently struggled with and since I didn’t find much help on the web, I thought I’d contribute. If you’re trying to hit WCF services (ours are RESTful but I’m pretty sure this happens on regular services as well), you may get weird security exceptions like this:
at System.Net.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult) at System.Net.BrowserHttpWebRequest.<>c__DisplayClass5.
b__4(Object sendState) at System.Net.AsyncHelper.<>c__DisplayClass2. b__0(Object sendState)
This can happen even if you’re using a clientaccesspolicy.xml file which is supposed to be one of the supported ways to get around cross domain issues in Silverlight according to Microsoft. Problem is, that doesn’t seem to be true. I examined the requests on the wire using Wireshark and what was actually happening was that my Silverlight application was asking for the clientaccesspolicy.xml and the server was responding with a 304 Unchanged status. Silverlight didn’t seem to know what to do with this so it would continue to throw the SecurityException above.
As it turns out, the crossdomain.xml file is the way to go if you want to have your Silverlight application talk to WCF. Put this at the web root and suddenly, everything works like a champ. Funny how the crossdomain.xml file is from Flash, the very application Silverlight is trying to take market share from.
Irony. It’s what’s for breakfast.