Getting Started with Silverlight Using Expression Blend

In the late 2000s, "rich internet applications" — highly interactive, animated, media-heavy experiences that ran inside a web page — were a major front in the browser wars. Microsoft's entry was Silverlight, and its companion design tool was Expression Blend. This guide is a retrospective: a conceptual tour of how the two worked together, aimed at anyone who has encountered an old reference to them and wants to understand what they were for.

What Silverlight was

Silverlight was a browser plug-in for building and running rich internet applications. Once installed, it let a web page host content that ordinary HTML of the era could not easily deliver: smooth vector graphics, animation, streaming audio and video, and interactive interfaces. Conceptually it was a cross-browser, cross-platform subset of Microsoft's WPF and .NET stack — a slimmed down version of the same UI technology used in desktop Windows applications, repackaged to run inside the browser sandbox rather than on the desktop.

That lineage is the key thing to understand. Windows Presentation Foundation (WPF) had introduced a way of describing user interfaces declaratively, in an XML-based language called XAML, and of programming their behaviour in .NET languages. Silverlight took a portion of that model to the web. A developer who already knew the desktop stack could bring much of that knowledge to a browser target, subject to the smaller feature set the plug-in exposed. Silverlight went through several versions over its lifetime, and its exact capabilities and programming model changed between them, so it is safest to think of it as a family of releases rather than a single fixed product.

What Expression Blend was

Expression Blend was Microsoft's visual design tool for building WPF and Silverlight interfaces. Where a code editor asks you to type markup, Blend gave you a design surface: you dragged shapes, controls, images and media onto a canvas, positioned and styled them, drew paths, defined animations on a timeline, and arranged the layout by eye. Behind the scenes, every one of those visual actions was recorded as XAML — the same declarative UI language that WPF and Silverlight consumed.

This is the single most important idea in the whole Silverlight-plus-Blend story: Blend did not use a separate, proprietary format. It authored the same XAML the runtime executed. The designer was manipulating a visual representation of the real UI, not a mock-up that later had to be re-implemented by hand. What you built in Blend was, quite literally, the interface that would ship.

How the pieces fit together

The intended division of labour looked like this:

• Design the interface visually in Expression Blend. Lay out the screen, style the controls, define visual states and animations. Blend writes the corresponding XAML.
• Write the application logic in Visual Studio. The behaviour — what happens when a button is clicked, how data is loaded, how the media player responds to controls — was code, and Visual Studio was the environment for writing and debugging it.
• Share one project between both tools. Because Blend and Visual Studio read and wrote the same XAML and project files, a designer and a developer could work on the same application without converting anything between them. Blend owned the look; Visual Studio owned the behaviour; the XAML in the middle was the shared contract.

The original zhanbos post that this page replaces pointed at a step-by-step Microsoft "QuickStart" that walked through exactly this workflow by building a small media player in Expression Blend 2, complete with screenshots. A media player was a natural showcase: it exercised layout, styling, interactive controls, and Silverlight's media playback all at once. The tutorial's premise — do the visual work in Blend rather than hand-writing XAML — is precisely the design-then-code split described above.

Why it mattered at the time

Silverlight arrived into a web that was, for rich interactive content, largely dominated by Adobe Flash. Flash was ubiquitous for games, video players, animation and interactive ads, and it had its own designer-oriented tooling and its own scripting language. Silverlight was Microsoft's challenger: it offered a comparable class of experience while letting teams build on the .NET skills, languages and tooling many Windows developers already had. Pairing the runtime with a dedicated visual designer in Expression Blend was part of that pitch — it gave designers a first-class tool rather than asking everyone to work in raw markup, directly answering the design-tool strength that Flash enjoyed.

For a few years this was a genuinely active area, with Silverlight used for media delivery, line-of business applications delivered through the browser, and interactive front-ends. It was a credible alternative in its window of relevance.

What happened, and where it stands today

The ground then shifted. The web moved decisively toward open standards — HTML5, CSS and JavaScript — which absorbed much of what previously required a plug-in: native video and audio, canvas and vector graphics, animation, and rich interactivity, all without installing anything. At the same time, browsers steadily removed support for the kind of plug-in architecture that Silverlight (and Flash) depended on. As that plug-in model disappeared from mainstream browsers, a browser-plug-in runtime had nowhere left to run.

Microsoft wound the platform down accordingly. Silverlight is discontinued and end-of-life. Microsoft ended support for Silverlight on 12 October 2021; it is no longer developed, and modern browsers generally cannot run Silverlight content. In practical terms: do not start anything new with it, and treat any surviving Silverlight application as legacy that needs migrating to web standards or to a supported UI stack.

The Expression brand faded too. The visual-design capability did not simply vanish, though — the Blend designer for XAML-based interfaces was carried forward as Blend for Visual Studio, integrated into Visual Studio itself rather than living on as a separate purchased product.

What lives on: XAML

Here is the reason this history is worth more than nostalgia. Silverlight, the browser plug-in, is gone — but XAML, the declarative UI language at the centre of the whole workflow, is very much alive. The modern Windows and .NET UI frameworks still describe their interfaces in XAML:

• WPF — the desktop framework Silverlight was originally a subset of — remains in use and supported for Windows desktop applications.
• WinUI — Microsoft's more recent native UI layer for Windows — likewise uses XAML for its interfaces.
• .NET MAUI — the cross-platform successor to Xamarin.Forms for building apps across multiple platforms from one codebase — also describes its UI in XAML.

So the specific skill of "hand-authoring a Silverlight plug-in app" is obsolete, but the more general skill — describing an interface declaratively in XAML, and separating that visual layer from the code that drives it — transferred almost intact. A developer who understood why you designed in Blend and coded in Visual Studio already understood the shape of how much modern .NET UI work is still organised.

The takeaway

Silverlight was Microsoft's plug-in for rich internet applications, a browser-hosted slice of the WPF and .NET world. Expression Blend was the visual tool that let you design those interfaces on a canvas while it wrote the XAML for you, with Visual Studio handling the logic on the same shared project. It was a serious contender against Flash in its day. The web then standardised on HTML5 and JavaScript, browsers dropped plug-ins, and Silverlight was retired. What endures is XAML and the design-then-code discipline it encouraged — both of which you will still find at the heart of WPF, WinUI and .NET MAUI today.