I took a long hiatus on playing with Silverlight plus Astoria solutions but I could hold back no longer. My impetus is that I am building a hands on lab for students in a full day "EF on the Web" workshop that I am teaching next week as part of the Cornerstone Developer Summit 2009 in fabulous Stockholm.

And my hiatus showed. I got stuck for hours on something so minor (and embarrassing) that I thought if I had this problem, some other poor soul might get stuck on it too.

The crux of my problem was the fact that I have done a bunch of work with Silverlight and WCF, so I was glazing over a key bit of information even though it was spelled out in every source I looked at - from the MSDN docs to John Papa's Data Services in Silverlight 2.0 book!

The problem was in how I was setting up my solution and cross-site scripting blocks. Cross-site scripting attacks generally occur when a web site points to another domain to get or send data to a service. If I have a Silverlight app hosted at www.devsource.com and I try to hit a service at www.amazon.com, it's probably something that amazon wants me to do. But what if I have a web service that I don't want the script kiddies to hack into? By default, services are locked down and can't be accessed from another domain. But the access can be opened up using either a ClientAccessPolicy.xml file or a CrossDomain.xml file. (John Papa talks about this in more detail in this MSDN article.)

When you are building a Silverlight app in Visual Studio, you will likely create a test web site to host it and that is more than likely going to be using the web development server, e.g., http://localhost:1234/mywebapp. Whether your service is using the web dev server (http://localhost:4321/myservice.svc) or IIS (http://localhost/myservice.svc) these will be different domains than the one your app is on (localhost:1234). Therefore, you will hit the cross-site scripting wall. No problem, just shove one of the files mentioned about into the service and configure it to accept calls from localhost:1234 and you are good to go.

Not so with Astoria services. This fix just won't work. So in the real world, you are hopefully hosting both your Silverlight app and your Astoria service on the same domain (e.g., www.devsource.com) and they will be happy to talk to each other. But when you are creating a solution in Visual Studio and you are using the web development server, there is a very specific pattern you must use.

I was not following this pattern because I was being a know-it-all and setting things up the way I had done so many times with Silverlight and WCF.

Here is the correct pattern.

• Step 1: Create a web site project to host the ADO.NET Data Service
• Step 2: Create the Silverlight app.
• Step 3: (THE CRITICAL PART THAT I WAS SKIPPING!!) When asked what host application to use, do not create a new project, but choose the project that contains your Astoria Service.This will mean that the same virtual web server which is spun up to host the service will also be used to host the Silverlight application and they will then be on the same domain (e.g., http://localhost:1234/)

Because I kept screwing up step 3, I went around in circles. I tried the cross-site scripting files. I even tried to force both the web app that was hosting my Silverlight app and the service onto the same port. That just will not work.

Finally I realized that all of my resources had told me about Step 3 but they hadn't done so in a way that hit me over the head with a frying pan in the way that was clearly required.