Introduction

Silverlight applications could not afford to block the UI thread during network calls, so WCF service access was typically asynchronous by design. In practice, that meant calling generated proxy methods such as GetCustomerAsync and handling a completion event when the response arrived.

Understand the Silverlight WCF Pattern

When you added a service reference in a Silverlight project, Visual Studio usually generated a client proxy that exposed asynchronous methods and corresponding completion events. Instead of writing:

var result = client.GetCustomer(42);

you wrote something closer to this:

var client = new CustomerServiceClient();
client.GetCustomerCompleted += Client_GetCustomerCompleted;
client.GetCustomerAsync(42);

This event-based asynchronous pattern kept the browser-hosted UI responsive while the network request ran in the background.

Call the Service and Handle Completion

A minimal Silverlight example looks like this:

1using System;
2using System.ServiceModel;
3using MyApp.ServiceReference1;
4
5public partial class MainPage
6{
7    private readonly CustomerServiceClient _client = new CustomerServiceClient();
8
9    public MainPage()
10    {
11        InitializeComponent();
12        _client.GetCustomerCompleted += OnGetCustomerCompleted;
13    }
14
15    private void LoadButton_Click(object sender, EventArgs e)
16    {
17        StatusText.Text = "Loading...";
18        _client.GetCustomerAsync(42);
19    }
20
21    private void OnGetCustomerCompleted(object sender, GetCustomerCompletedEventArgs e)
22    {
23        if (e.Error != null)
24        {
25            StatusText.Text = e.Error.Message;
26            return;
27        }
28
29        if (e.Cancelled)
30        {
31            StatusText.Text = "Request cancelled";
32            return;
33        }
34
35        NameText.Text = e.Result.Name;
36        StatusText.Text = "Loaded";
37    }
38}

The completion handler is where you inspect e.Result, check e.Error, and update the UI.

Keep the Service Contract Simple

On the server side, the WCF service contract can stay ordinary. The Silverlight client proxy is what generates the async method surface.

1[ServiceContract]
2public interface ICustomerService
3{
4    [OperationContract]
5    CustomerDto GetCustomer(int id);
6}

Silverlight then consumes the service asynchronously even if the original contract looks synchronous on the server. That separation is why many examples show async usage only on the client side.

Handle Errors and Timeouts Explicitly

Because the call completes later, you cannot rely on ordinary synchronous exception flow around GetCustomerAsync. Network problems, service faults, and serialization errors appear in the completed-event arguments.

It was also common to disable buttons or show a busy indicator while the request was in flight. Otherwise, users could trigger the same call repeatedly and create overlapping requests.

If the page or control could be unloaded before the response arrived, unsubscribing from events was also important to avoid updating a dead view.

Silverlight also imposed security and deployment constraints that made endpoint configuration important. If the service binding or address was wrong, the async call still returned through the completion path, but with an error that had to be handled intentionally.

Common Pitfalls

The most common mistake was trying to use WCF from Silverlight as if it were a normal blocking .NET desktop client. Silverlight network access was asynchronous for responsiveness and sandbox reasons, so synchronous assumptions led to broken UI flow.

Another issue was ignoring e.Error and reading e.Result unconditionally in the completed handler. Faulted calls did not produce a valid result object.

People also forgot to configure the service for Silverlight-friendly access, including the correct endpoint and, in cross-domain scenarios, the required policy files such as clientaccesspolicy.xml.

Finally, multiple event subscriptions could cause the completion handler to fire more than once per call if the client object was reused carelessly.

Summary

• Silverlight WCF clients typically used generated Async methods plus completion events.
• Start the request with a proxy call such as GetCustomerAsync(...).
• Read the result, error, and cancellation state inside the completed event handler.
• Keep the UI responsive by showing loading state while the call is in flight.
• Be careful with event subscriptions, endpoint configuration, and cross-domain access rules.