Consuming WCF Services in Silverlight

Analogy categoryAnalogies

Why Every Silverlight Service Call Is Asynchronous

Silverlight executes inside the browser plug-in sandbox on a single UI thread, and the runtime deliberately removes any synchronous network API from that thread so a slow service can never freeze the hosting page. Every WCF call you make from Silverlight is therefore asynchronous by design: you invoke a method, the request goes out on a background thread, and a callback or event fires when the response arrives, with the result marshaled back onto the UI thread automatically.

🏏

Cricket analogy: It's like a captain reviewing a DRS decision: play doesn't freeze while the third umpire checks replays, the game clock keeps ticking conceptually and the on-field umpire's final call arrives later as a callback, not something the captain waits on standing still.

Adding a Service Reference and the Generated Proxy

When you right-click a Silverlight project and choose Add Service Reference, Visual Studio inspects the service's WSDL and generates a client-side proxy whose methods are suffixed with Async, such as GetCustomerAsync, paired with a corresponding CustomerCompleted event you subscribe to. The generated configuration is written to ServiceReferences.ClientConfig rather than app.config or web.config, because the XAP has no app-domain configuration file of its own and the runtime reads endpoint bindings from that special resource instead.

🏏

Cricket analogy: It's like the scorer's automated system auto-generating a scorecard template from the match officials' pre-filled team sheet, so the analyst just fills in runs and wickets instead of drawing rows and columns from scratch every innings.

Handling Responses, Errors, and Cross-Domain Access

In the event-based asynchronous pattern that Silverlight service proxies use, every Completed event hands you an EventArgs subclass exposing an Error property that must be checked before touching Result, because an unhandled fault on the service side surfaces as a populated Error rather than a thrown exception on the call site. The framework's SynchronizationContext captures the UI thread at call time and automatically marshals the callback back onto it, so you can safely update bound UI elements like a ListBox or TextBlock directly inside the Completed handler without an explicit Dispatcher.BeginInvoke.

🏏

Cricket analogy: A third umpire reviewing a run-out doesn't just signal 'out' or 'not out' silently; the decision comes back with a reason code shown on the big screen, just as the Completed event carries an Error property you must inspect before trusting the Result.

Cross-Domain Policy Files

If the WCF service lives on a different domain than the one hosting the XAP file, Silverlight's network stack refuses the request unless the target domain publishes a clientaccesspolicy.xml file at its web root, or a compatible crossdomain.xml, explicitly granting the calling domain permission; this is a browser-style same-origin protection carried into the plug-in to prevent a malicious page from silently harvesting data from an unrelated service the user happens to be authenticated to.

🏏

Cricket analogy: A touring team can't just walk onto a foreign board's home ground and start practicing; the host cricket board must issue explicit clearance and ground access permission first, just as a foreign domain must publish clientaccesspolicy.xml before Silverlight's requests are allowed through.

csharp

// Proxy generated by Add Service Reference for a CustomerService WCF endpoint
CustomerServiceClient client = new CustomerServiceClient();
client.GetCustomerCompleted += (s, e) =>
{
    if (e.Error != null)
    {
        StatusText.Text = "Failed to load customer: " + e.Error.Message;
        return;
    }

    // Safe to touch UI directly - callback is marshaled to the UI thread
    Customer customer = e.Result;
    NameTextBlock.Text = customer.FullName;
    CustomerListBox.ItemsSource = customer.Orders;
};

client.GetCustomerAsync(customerId);

Silverlight also supports ChannelFactory<T> for building a proxy at runtime instead of a designer-generated one, which is useful when the endpoint address isn't known until runtime (for example, resolved from a configuration service). The binding and contract rules are identical to the generated proxy - only basicHttpBinding (and later, limited support for custom bindings over HTTP) is usable from the browser sandbox.

Out-of-browser Silverlight apps running with elevated trust can use additional bindings and open raw sockets, but standard in-browser Silverlight is restricted to basicHttpBinding-style plain SOAP or POX/JSON endpoints over HTTP - wsHttpBinding, WS-Security headers, and duplex TCP bindings are not available to a normal in-browser client, so services must be designed or wrapped accordingly.

All Silverlight-to-WCF calls are asynchronous; there is no synchronous invocation API on the UI thread.
Add Service Reference generates Async methods and Completed events, configured via ServiceReferences.ClientConfig.
Always check e.Error before reading e.Result inside a Completed handler.
The SynchronizationContext marshals callbacks back to the UI thread automatically, so bound controls can be updated directly.
Cross-domain calls require a clientaccesspolicy.xml or crossdomain.xml published on the target domain.
In-browser Silverlight is effectively limited to basicHttpBinding-style endpoints over plain HTTP.
ChannelFactory<T> is an alternative to the generated proxy for runtime-resolved endpoints, under the same binding restrictions.