Silverlight vs WPF

Analogy categoryAnalogies

Overview

Silverlight and Windows Presentation Foundation (WPF) share a common heritage: both use XAML markup to declare UI trees, both support data binding, styles, templates, and dependency properties, and both descend from the same design philosophy Microsoft introduced with .NET 3.0 in 2006. However, WPF is a full desktop UI framework running on the complete .NET Framework with direct access to Win32, COM, and the local file system, while Silverlight is a deliberately trimmed subset designed to run safely inside a browser sandbox, which means large parts of WPF's API surface simply do not exist in Silverlight.

🏏

Cricket analogy: WPF and Silverlight are like a full Test match squad of 15 versus the trimmed 11-player XI actually sent onto the field for a T20 game, same core cricketing DNA and selection process, but one carries far more reserve capability than the other.

Rendering and Threading

WPF renders through DirectX with full access to hardware-accelerated composition, retained-mode graphics, and integration with Win32 windows (HwndHost), and it supports multiple UI threads and dispatcher objects across separate windows in the same process. Silverlight also uses retained-mode, vector-based rendering but through its own lightweight compositor tuned for browser embedding, and it enforces a single UI thread per plugin instance with a much stricter dispatcher model, since it must coexist safely inside the host browser's process and cannot assume exclusive control of the GPU pipeline the way a desktop app can.

🏏

Cricket analogy: WPF's multi-window, multi-threaded rendering is like a stadium running simultaneous replay screens for the big screen, dugout monitors, and broadcast feed independently, while Silverlight's single UI thread is like a single shared monitor that every viewer must watch in the same sequence.

APIs and Class Library Differences

Because Silverlight targets an untrusted browser sandbox, its base class library is a curated subset of the full .NET Framework: reflection is restricted (no access to private members across security boundaries by default), there is no arbitrary System.IO file access outside isolated storage, no direct database connectivity like ADO.NET's full provider model, and networking is limited to HTTP(S) and sockets under cross-domain policy files (clientaccesspolicy.xml or crossdomain.xml). WPF, by contrast, has the entire .NET Framework at its disposal, including full file I/O, registry access, P/Invoke into native Win32 APIs, and unrestricted reflection, because it runs as a fully trusted desktop process.

🏏

Cricket analogy: Silverlight's restricted networking under a crossdomain.xml policy is like a touring team needing prior written clearance from the host cricket board before playing any match on foreign soil, while WPF is like the home team that can schedule fixtures freely.

Deployment and Hosting

A WPF application deploys as a standalone .exe (optionally via ClickOnce for auto-updating installs) that runs directly on the Windows desktop with its own top-level window, taskbar entry, and full OS integration. A Silverlight application, by contrast, deploys as a .xap file hosted inside an HTML page and rendered within the bounds of the browser's plugin object element; later versions added an 'out-of-browser' (OOB) mode that let users install a Silverlight app to run outside the browser with its own window, and an 'elevated trust' mode for OOB apps that unlocked broader file system and COM access closer to what WPF enjoyed natively.

🏏

Cricket analogy: A WPF .exe is like a franchise with its own dedicated home stadium and full infrastructure, while a Silverlight .xap hosted in a browser page is like a touring team playing in a shared neutral venue it doesn't control, at least until out-of-browser mode gives it a semi-permanent ground.

xml

<!-- WPF: full Grid + Button, standard WPF namespaces, hosted in a native Window -->
<Window x:Class="WpfDemo.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="WPF Window" Height="200" Width="300">
    <Grid>
        <Button Content="Save to Disk" Click="SaveButton_Click" />
    </Grid>
</Window>

<!-- Silverlight: same-looking XAML, but hosted in a UserControl inside the browser plugin,
     and SaveButton_Click cannot write to arbitrary disk paths — only IsolatedStorageFile -->
<UserControl x:Class="SilverlightDemo.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Grid>
        <Button Content="Save to Isolated Storage" Click="SaveButton_Click" />
    </Grid>
</UserControl>

A common migration mistake is assuming WPF code will compile unchanged against Silverlight. APIs like System.IO.File.Open, full System.Data/ADO.NET, unrestricted Reflection, and P/Invoke are unavailable in standard (non-elevated-trust) Silverlight — always check the Silverlight class library reference before porting WPF code.

WPF and Silverlight share XAML, data binding, styles, and dependency properties from the same .NET 3.0-era design.
WPF is a full desktop framework with complete .NET Framework and Win32/COM access; Silverlight is a sandboxed browser subset.
WPF supports multiple windows and dispatcher threads; Silverlight enforces a single UI thread per plugin instance.
Silverlight restricts reflection, file I/O (isolated storage only), and cross-domain networking via policy files.
WPF deploys as a standalone .exe (optionally ClickOnce); Silverlight deploys as a .xap hosted in an HTML page.
Out-of-browser (OOB) mode let Silverlight apps run outside the browser; elevated trust unlocked broader file/COM access.
Always verify API availability before porting WPF code to Silverlight — many BCL members simply don't exist there.