Data-Driven Silverlight

I’m continuing the struggle with Silverlight, and I’d like to share my probably worst experience with you. I’d wanted to make a data-driven app in Silverlight recently, but it took a complete day. All I wanted was the binding of a MS SQL table to a Silverlight DataGrid. Because SL doesn’t support System.Data (which made me cry at the first place), I needed a workaround for this one. Then I found the template Silverlight-enabled WCF service, and it was love in the first sight, I thought. To bind a table (one-way binding, of course) in Silverlight is relatively easy. Create a service, set a reference on it, set it as the ItemSource property of the DataGrid. In code:

WebServiceSoapClient client = new WebServiceSoapClient();

client.GetCustomersCompleted += new EventHandler<GetCustomersCompletedEventArgs>(client_CustomersCompleted);

void client_CustomersCompleted(object sender, GetCustomersCompletedEventArgs e)


dataGrid1.ItemsSource = e.Result;


Easy as that.

But there was an error, an exception, probably the one I’ve seen the most: NotFoundException. Web services in .NET have this funny exception, which they throw for literally everything. Of course there are Inner Exceptions, at least a dozen, but all of them was this NotFoundException.

I started to google, and found a solution: Fiddler! Sounded like a charm, this tool will tell me exactly what happening behind the scenes, even the real exception, which triggered the notfound one. Download, install, build project, frenzy. Fiddler cannot monitor localhost.

Okay, then why not deploy the site as local IIS. Let’s go! And that’s it, fiddler catches a detailed exception message, I’m saved, but that’s not the case. Something about clientaccessploicy.xml. Google: as the name suggests, it is used for setting the client access policies of Flash and Silverlight. To enlighten everyone, here’s a sample, which allows anything to everybody:

<?xml version=”1.0″ encoding=”utf-8″ ?>
      <allow-from http-request-headers=”*”>
        <domain uri=”*”></domain>
        <resource path=”/” include-subpaths=”true”></resource>

This must be put in the root directory of the domain/page, and nowhere else. With clientaccesspolicy.xml in place, no one can stop me from getting my precious data and press it into a nice, fancy Silverlight datagrid. And here comes enlightenment: I made an error in the service host (some nullreference exception). I’m looking dumb at my monitor, and ask myself, why? Why did it had to be this way. Fiddler told me, it was there black and white: you dumb asshole, you tried to create a class without first checking whether is it exist or not. Okay.

 Then I saw my beloved customers being requested from my service, even sent, but still saw nothing in my Silverlight app. I considered the amount of them sent to be too much, so I reformatted my LINQ expression with some where clauses, then finally, I could take a glance of my customers at 2 am. in a shiny, well-formatted Silverlight datagrid.

So, the point is: when you working with services, always check BOTH ends twice. And install Fiddler. And deploy your service somewhere. Then include a clientaccesspolicy.xml. And keep on fighting! Never surrender!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s