Question

I have a Silverlight 4 application which talks to a ‘manager’ class, which talks to a WCF Service ( .net 4) , which uses the Microsoft.ApplicationBlocks.Data library to talk to my SQL database.

My issue is with exceptions not bubbling up to the Silverlight App.

What happens is, an insert to the database fails, creating an SQLException, this then throws the error further, to the generated service reference code used by the Manager, which, in the completed event handler, finds that the Error property is not null. This throws an event to the Silverlight app which displays a message to the user saying that an error has occured.

This works when I am locally debugging my application but fails silently when the appliaction is on the live/production server, no error message gets displayed.

If I generate the service reference from the wcf service running on the server (not locally), and use a local instance of my Silverlight App, it also works correctly which makes me think that the error is happening in the service reference (generated code) and Silverlight communication.

The service is hosted in a ‘hand-coded’ host application and the Silverlight app on the server is hosted in IIS. They both use http and not https.

I have scoured the Internet but found nothing that relates to this situation. I do not kill off objects, therefore preventing exceptions being returned to non-existant objects.

In short, the Manager correctly recieves and throws an event on my local system but not when deployed on the server.

WCF Experts needed please!

Answer 1

So, after some more fruitless searching, my collegue built a test app where he built a custom silverlight Fault Contract class based on this example:
http://msmvps.com/blogs/theproblemsolver/archive/2009/01/27/returning-exception-information-to-a-silverlight-client-through-wcf.aspx

Although this helped alot with getting the specific error from the service instead of the generic garbage Silverlight spews, we could still not get the error to display on the screen.

My previous guess that the communication was failing was incorrect. Instead, it was simply the fact that the result did not have any effect on the UI Thread. We used the Dispatcher to jump back onto the UI Thread:

Deployment.Current.Dispatcher.BeginInvoke(
            () =>
            {
                //throw event to window which shows error window
            }
            );

which displayed the true error. I still do not know exactly why this was required for the app on the Production server but it worked fine on my localhost, in debug mode or not.

If anyone with more knowledge about the technicalities of this occurance reads this, please be so kind as to explain what really happened here.