Contrasting Silverlight and WPF

Silverlight and Windows Presentation Foundation (WPF) both allow you to develop rich user experience applications based on XAML and the .NET Framework. However, there are some differences between these platforms, and these differences have to be carefully considered when transitioning an application between Silverlight and WPF or when building an application that targets both WPF and Silverlight.

Note

This topic describes differences between Silverlight 2.0 and WPF that is part of the .NET Framework 3.5. These differences are expected to be reduced in future versions of Silverlight and WPF.

Silverlight and WPF Architectural Overview

Windows Presentation Foundation (WPF) provides developers with a unified programming model for building rich Windows Forms applications that incorporate user interface (UI), media, and documents. WPF enables software developers to deliver a new level of "user experience" (UX) by providing a declarative-based language (XAML) for specifying vector-based graphics that can scale and take advantage of hardware acceleration.

Silverlight is a cross-browser, cross-platform implementation of the .NET Framework for delivering next-generation rich interactive media and content over the Web and for developing browser-hosted Rich Internet Applications (RIAs) that can integrate data and services from many sources. Silverlight enables developers to build applications that significantly enhance the typical end user experience, compared with traditional Web applications. Like WPF, Silverlight provides a XAML-based language to specify user interfaces.

Silverlight and WPF share many of the same features and capabilities, but they are built on top of different run-time stacks, as illustrated in Figure 1. WPF leverages the full .NET Framework and executes on the common language runtime (CLR). Silverlight is based on a subset of XAML and the full .NET Framework, and it executes on a browser-hosted version of the CLR.

Figure 1

WPF and Silverlight

For more information about WPF architecture, see WPF Architecture on MSDN. For more information about Silverlight architecture, see Silverlight Architecture on MSDN.

Differences Between Silverlight and WPF

To keep Silverlight small and lightweight, some WPF and .NET Framework features are not available in Silverlight. Because of this, there can be subtle—and not so subtle—differences that have to be carefully considered when moving an application between Silverlight and WPF or when building an application that targets both WPF and Silverlight. For a summary of these differences, see WPF Compatibility on MSDN.

This section describes some of the major differences the patterns & practices team encountered during the development of the Composite Application Guidance for WPF and Silverlight. These differences relate to Silverlight 2.0 and WPF 3.5, the current versions at the time of this writing.

Resources

Resources are simple collections of key-value pairs that can store almost any element (strings, brushes, styles, data sources, and many others). Resources can be associated with almost any element class that exposes a Resources property of type ResourceDictionary. The following are the main differences between Silverlight and WPF concerning resources:

• Resources can contain static or dynamic content. Dynamic content can be changed at any time and consumers of the resource will be automatically updated. Dynamic resource references are not supported in Silverlight; therefore, only static resource references are available.
• Merged dictionaries are useful for separating resources so that they can be shared within the application as if they were in a single logical location. Silverlight does not currently support MergedDictionaries. Global resources can be defined in the App.xaml file or locally in each user control that will use the resource.

Styles

There are several differences between Silverlight and WPF when using styles. You should be aware of the following limitations in Silverlight:

• After you set a style to a FrameworkElement at run time, it cannot be subsequently changed.
• Style inheritance is not supported, because the BasedOn property is not available.
• Silverlight does not support implicit styles applied using the TargetType attribute value. If you define an application-level style for a specific user control, it will not be automatically applied to all instances of the user control; instead, you must explicitly reference the style by its key for each control instance.

Triggers

Triggers allow designers to define the visual behavior of a control by declaratively specifying how its properties change in response to events or property changes, such as highlighting a button when it is clicked. Typically, triggers are fired when a property of a control changes and results in one or more other properties of that control also changing. Triggers are defined inside a style and can be applied to any object of the specified target type.

Silverlight does not support triggers in Styles, ControlTemplates, or DataTemplates (the Triggers collection does not exist on these elements). However, similar behavior can be achieved by using the Silverlight Visual State Manager (VSM) to define interactive control templates. Using VSM, the visual behavior of a control, including any animations and transitions, are defined in the control template. This can be easily done by using Blend 2.5. However, be aware that the XAML file will get more complex and that control templates built for Silverlight are not yet compatible with WPF.

For more information about the Visual State Manager, see Creating a Control That Has a Customizable Appearance on MSDN.

Note

At the time of writing, the VSM is planned to be supported in the next version of WPF. A preview of a Visual State Manager for WPF is available on CodePlex in the WPF Toolkit.

Data Binding

Both WPF and Silverlight provide data binding support. The following are the main differences between Silverlight and WPF data binding:

• In Silverlight, there is no support for the ElementName property in the binding syntax, so the property of a control cannot be bound to a property in another control. In addition, Silverlight does not support the RelativeSource property, which is useful when the binding is specified in a ControlTemplate or a Style.
• In Silverlight, there is no OneWayToSource data flow mode.
• In Silverlight, there is no UpdateSourceTrigger property. All updates to the source in the two-way binding mode occur immediately, except in the case of TextBox, in which case changes are propagated to the source when the focus is lost.
• In Silverlight, you cannot bind directly to XML data. A possible workaround for this is to convert the XML to CLR objects, and then bind to the CLR object.
• In Silverlight, there is no XMLDataProvider class.
• In Silverlight, there is no support for binding validation rules. Controls in Silverlight can be configured to raise an event to indicate that a validation error has occurred.
• In Silverlight, there is no ReadOnlyObservableCollection; however, ObservableCollection is supported. ReadOnlyObservableCollection is a read-only wrapper around the ObservableCollection. The ObservableCollection represents a dynamic data collection that provides notifications when items get added, removed, or when the whole collection gets refreshed.
• In Silverlight, there is no CollectionView class. In WPF, this class represents a view for grouping, sorting, filtering, and navigating a data collection. The ICollectionView interface is available in Silverlight; by using this, developers can create their own CollectionView implementations, although most Silverlight controls do not automatically interact with this interface.
• In Silverlight, there is no DataTemplateSelector class. In WPF, this class provides a way to choose a DataTemplate based on the data object and the data-bound element.

Commanding

The following are the differences between Silverlight and WPF regarding commanding:

• Routed commands are not available in Silverlight. However, the ICommand interface is available in Silverlight, allowing developers to create their own custom commands. The Composite Application Library provides the DelegateCommand and CompositeCommand classes to simplify command implementation. For more information, see the Commands technical concept.
• In WPF, controls can be hooked up to commands through their Command property. By doing this, developers can declaratively associate controls and commands. This also means a control can interact with a command so that it can invoke the command and have its enabled status automatically updated. Silverlight controls do not currently support the Command property. To help work around this issue, the Composite Application Library provides an attached property-based extensibility mechanism that allows commands and controls to be declaratively associated with each other. For more information, see "Using Commands in Silverlight Commands" in the Commands technical concept.
• There is no input gesture or input binding support in Silverlight.

Miscellaneous

The following are some miscellaneous differences between Silverlight and WPF:

• In Silverlight, the UIElement class has an internal constructor; therefore, you cannot create a control inheriting from it.
• In Silverlight, there is no x:type markup extension support or support for custom markup extensions.
• In Silverlight, items added to a TabControl control are not automatically wrapped inside a TabItem type, as is the case with WPF.

More Information

For information about creating multi-targeted applications in WPF and Silverlight, see the following topics:

• Multi-Targeting design concept
• Multi-Targeting technical concept
• Multi-Targeting QuickStart
• Project Linker: Synchronization Tool

Home page on MSDN | Community site