Introduction

When HttpWebRequest.Create appears to hang in a Silverlight async flow, the real problem is often not the Create call itself. In many cases the application is blocked by the surrounding async pattern, UI-thread synchronization, or a network restriction that only becomes visible at that point in the code. Because Silverlight is a legacy client runtime with a constrained networking model, the safest fix is usually to simplify the request flow rather than layering more async wrappers on top of it.

Understand What Create Is Supposed to Do

HttpWebRequest.Create normally just constructs a request object for a URI. It does not perform the network round trip by itself. If the code looks hung on that line, there are a few common explanations:

1. The debugger is stopping at the first line after a blocked earlier continuation.
2. The UI thread is deadlocked by waiting on an async result.
3. The runtime is resolving networking or policy information and the actual issue is environmental.

That distinction matters because it changes the debugging strategy. If object creation is not the real bottleneck, replacing Create rarely solves anything.

Avoid Blocking the UI Thread Around Async Work

One of the most common Silverlight mistakes is mixing asynchronous network operations with synchronous waits. That can deadlock the UI thread or make the code look frozen.

A problematic pattern looks like this:

1public string LoadSynchronously(string url)
2{
3    var task = DownloadAsync(url);
4    return task.Result;
5}

If DownloadAsync tries to resume on the UI context, Result can block the very thread that the continuation needs. The safer pattern is to keep the whole call chain asynchronous.

1public async Task<string> LoadAsync(string url)
2{
3    return await DownloadAsync(url);
4}

In Silverlight-era code, even when async and await are introduced later, the core rule remains the same: do not force network calls back into synchronous flow.

Use the Request Object in a Clean Async Pattern

Silverlight networking is designed around asynchronous request and response handling. A straightforward wrapper around BeginGetResponse is more reliable than pushing request creation into arbitrary background tasks.

1using System;
2using System.IO;
3using System.Net;
4using System.Threading.Tasks;
5
6public static class Downloader
7{
8    public static Task<string> DownloadAsync(string url)
9    {
10        var tcs = new TaskCompletionSource<string>();
11        var request = (HttpWebRequest)WebRequest.Create(url);
12
13        request.BeginGetResponse(ar =>
14        {
15            try
16            {
17                using (var response = (HttpWebResponse)request.EndGetResponse(ar))
18                using (var stream = response.GetResponseStream())
19                using (var reader = new StreamReader(stream))
20                {
21                    tcs.SetResult(reader.ReadToEnd());
22                }
23            }
24            catch (Exception ex)
25            {
26                tcs.SetException(ex);
27            }
28        }, null);
29
30        return tcs.Task;
31    }
32}

This keeps the object creation, network start, and completion flow in one coherent place. It is usually easier to debug than wrapping Create itself in Task.Run or another background abstraction.

Check Silverlight-Specific Network Constraints

Silverlight historically had stricter networking constraints than full desktop .NET. If the request seems stuck, validate the environment:

1. Confirm the URI is valid and reachable.
2. Check cross-domain policy requirements if the target is remote.
3. Verify that the application is not waiting on a proxy or blocked network path.
4. Make sure exceptions from the response callback are surfaced instead of swallowed.

A request that never completes is often a connectivity or policy problem that looks like an async bug because the error is not being observed properly.

Prefer Simpler APIs When Possible

If the scenario is straightforward HTTP download rather than fine-grained request control, WebClient can be easier to reason about in older Silverlight code.

1using System;
2using System.Net;
3
4public static void DownloadWithWebClient(string url)
5{
6    var client = new WebClient();
7    client.DownloadStringCompleted += (sender, args) =>
8    {
9        if (args.Error != null)
10        {
11            Console.WriteLine(args.Error.Message);
12            return;
13        }
14
15        Console.WriteLine(args.Result);
16    };
17
18    client.DownloadStringAsync(new Uri(url));
19}

That does not make every problem disappear, but it removes some ceremony and can narrow the debugging surface.

Debug the Flow, Not Just the Suspicious Line

When legacy async code looks frozen, the best debugging questions are:

1. Which thread is blocked?
2. Which callback or continuation never fires?
3. Is the exception path being observed?
4. Is the target endpoint actually reachable from the runtime?

Treating the line with HttpWebRequest.Create as the sole suspect often wastes time. In older client frameworks, the visible symptom and the actual cause are frequently separated.

Common Pitfalls

• Calling .Result or .Wait() on async network work and blocking the UI thread.
• Wrapping HttpWebRequest.Create in extra background-task logic instead of fixing the surrounding async flow.
• Ignoring Silverlight network restrictions such as policy or endpoint reachability.
• Swallowing exceptions inside callbacks and then interpreting silence as a hang.
• Using a complex request abstraction when a simpler WebClient flow would be easier to validate first.

Summary

• 'HttpWebRequest.Create is usually not the true source of the hang; the surrounding async pattern often is.'
• Keep network code asynchronous end to end and avoid synchronous waits on the UI thread.
• Use a clean request wrapper around BeginGetResponse if you need HttpWebRequest.
• Validate network reachability and Silverlight-specific constraints before blaming the API surface.
• Simplify the flow first, then debug where the continuation or callback actually stops.