Silverlight Debugging

Analogy categoryAnalogies

Debugging Silverlight Applications

Debugging Silverlight is harder than debugging a normal desktop app because the runtime executes inside a browser plug-in sandbox, network calls are asynchronous by design, and binding errors report only to the Output window rather than throwing exceptions. Effective Silverlight debugging combines Visual Studio's managed debugger attached to the plug-in process, the XAML binding trace output, and, for network issues, an HTTP inspector like Fiddler sitting between the browser and the server.

🏏

Cricket analogy: Diagnosing why a bowler is losing pace requires watching the full run-up on video, checking the pitch conditions, and reviewing the speed gun readings together, just as Silverlight debugging combines the managed debugger, binding trace output, and network inspection.

Reading Binding Errors from the Output Window

Silverlight does not throw exceptions for a failed binding; instead it writes a BindingExpression error to the Visual Studio Output window when running under the debugger, describing the source property, target property, and the reason resolution failed — typically a typo in the property Path, a missing DataContext, or a type conversion failure. Because this trace is easy to miss among other diagnostic noise, developers should get in the habit of scanning the Output window immediately whenever a control shows unexpected blank or default content.

🏏

Cricket analogy: A no-ball called by the umpire but only announced quietly over the stadium PA can be missed by players focused on the game, similar to a BindingExpression error logged only to the Output window and easy to overlook.

Debugging Threading and Asynchronous Calls

Because nearly all Silverlight network APIs — WebClient, HttpWebRequest, and service proxies generated from a service reference — are asynchronous-only, bugs frequently manifest as code that appears to run out of order in the debugger, or breakpoints that never seem to hit because the callback executes later than expected. Setting a breakpoint inside the *Completed event handler and inspecting the call stack there, rather than trying to step through from the call site, is the reliable way to trace what actually happened; the Locals window at that point shows the real state after the network round-trip completed.

🏏

Cricket analogy: Reviewing a run-out replay from the third umpire's monitor after the fact, rather than trying to judge it live at full speed, is the only reliable way to see what really happened, similar to inspecting a Completed handler's breakpoint instead of stepping through the async call site.

csharp

var client = new WebClient();
client.DownloadStringCompleted += (s, e) =>
{
    // Set your breakpoint HERE, not on the line below that calls DownloadStringAsync.
    if (e.Error != null)
    {
        System.Diagnostics.Debug.WriteLine("Download failed: " + e.Error.Message);
        return;
    }
    System.Diagnostics.Debug.WriteLine("Received " + e.Result.Length + " chars");
};
client.DownloadStringAsync(new Uri("http://example.com/data.json", UriKind.Absolute));

Use System.Diagnostics.Debug.WriteLine liberally around async boundaries during development — Silverlight's async call stacks in the debugger can be misleading, but Debug output gives you a reliable, ordered timeline of what actually executed and when, visible directly in the Visual Studio Output window.

Diagnosing Cross-Domain and Network Failures

A WebClient or HttpWebRequest call to a domain other than the one hosting the .xap file will fail unless the target server exposes a clientaccesspolicy.xml or crossdomain.xml file at its root granting access; when this policy file is missing or misconfigured, the failure surfaces generically as a SecurityException or a null Result with no HTTP status code, which is easy to mistake for a server outage. Attaching Fiddler as a system proxy while reproducing the issue reveals whether the browser even attempted the policy file request, and if so, what the server actually returned for it.

🏏

Cricket analogy: A player denied entry to an opposing team's dressing room without prior clearance gets turned away at the door with no detailed explanation, similar to a cross-domain call failing generically when no clientaccesspolicy.xml grants access.

A missing clientaccesspolicy.xml does not throw a descriptive exception in most cases — the async callback simply fires with e.Error set to a generic SecurityException or the response comes back empty. Always confirm cross-domain policy files exist and are correctly scoped (grant-to domain, allowed HTTP methods, allowed headers) before assuming the problem lies elsewhere.

Silverlight binding failures log to the Visual Studio Output window instead of throwing exceptions — check it whenever a control shows unexpected blank content.
Nearly all Silverlight network calls are asynchronous-only; set breakpoints inside *Completed handlers, not at the call site.
Use Debug.WriteLine around async boundaries to build a reliable timeline of execution order.
Cross-domain calls require a clientaccesspolicy.xml or crossdomain.xml on the target server, or they fail with a generic SecurityException.
Fiddler as a system proxy reveals whether the policy file request happened and what the server returned.
A generic SecurityException or empty Result on a network call is a strong signal to check cross-domain policy configuration first.
Combine the managed debugger, binding trace output, and an HTTP inspector for a complete diagnostic picture.