An Experiment in Scotch

From the pub­lic ser­vice announce­ment depart­ment, this is an issue I recently strug­gled with and since I didn’t find much help on the web, I thought I’d con­tribute. If you’re try­ing to hit WCF ser­vices (ours are REST­ful but I’m pretty sure this hap­pens on reg­u­lar ser­vices as well), you may get weird secu­rity excep­tions 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 hap­pen even if you’re using a clientaccesspolicy.xml file which is sup­posed to be one of the sup­ported ways to get around cross domain issues in Sil­verlight accord­ing to Microsoft. Prob­lem is, that doesn’t seem to be true. I exam­ined the requests on the wire using Wire­shark and what was actu­ally hap­pen­ing was that my Sil­verlight appli­ca­tion was ask­ing for the clientaccesspolicy.xml and the server was respond­ing with a 304 Unchanged sta­tus. Sil­verlight didn’t seem to know what to do with this so it would con­tinue to throw the Secu­ri­tyEx­cep­tion above.

As it turns out, the crossdomain.xml file is the way to go if you want to have your Sil­verlight appli­ca­tion talk to WCF. Put this at the web root and sud­denly, every­thing works like a champ. Funny how the crossdomain.xml file is from Flash, the very appli­ca­tion Sil­verlight is try­ing to take mar­ket share from.

Irony. It’s what’s for breakfast.