WPF Compatibility

There is no Flow Document support in Silverlight. For more information, see Flow Document Overview in the WPF documentation.

Silverlight does not support dynamic resources. All resource references to keyed resources in XAML are static. For more information, see Resources Overview.

In addition to the features previously listed, the following are supported in WPF but not in Silverlight:

• TileMode property for TileBrush objects.

• ValueConversion attribute.

• ITyped list, InstanceFactory, or BindingList(T).

• Electronic Documentation Management (EDM).

The basics of Silverlight and WPF data binding are the same. However, there are some data-binding features offered in WPF that are not available in Silverlight. Silverlight supports binding the DependencyProperty of a FrameworkElement (and in some cases a DependencyObject) to any CLR object. Silverlight does not provide any of the following:

• Datasets.

• ICustomTypeDescriptor, IListSource, or IBindingList.

• Binding directly to XML data or XPath binding. (The recommended alternative is to use the System.Xml.Linq API for XML business objects.)

• BindingMode.OneWayToSource binding.

• Discrete notification for source and target updates with dedicated NotifyOnSourceUpdated or NotifyOnTargetUpdated properties (and related events) on a binding.

• Bindable Run.

Additionally, Silverlight does not support some of the binding options that WPF supports. For more information, see Binding Markup Extension and Property Path Syntax.

Silverlight does provide value converters and support for data validation. This includes support for the INotifyDataErrorInfo interface.

For more information, see Data Binding.

WPF (particularly in .NET Framework 3.5) uses the concept of triggers. Triggers enable you to make property changes or start actions when events occur or properties change. Silverlight support for triggers is limited to using the EventTrigger object for the Loaded event and the BeginStoryboard action. However, everything that triggers were used for in previous WPF XAML can be accomplished by using the VisualStateManager model. For more information, see Customizing the Appearance of an Existing Control by Using a ControlTemplate or Creating a New Control by Creating a ControlTemplate.

WPF introduced the concept of routed events, where an event can be handled by multiple handlers in the element tree instead of just the object that initiated the event. For more information about routed events from the WPF perspective, see Routed Events Overview in the WPF documentation.

Silverlight includes the concept of routed events for a small subset of events. However, Silverlight does not enable you to create a new routed event. In addition, Silverlight does not include Preview events or class-handling of routed events. Silverlight user code can re-handle a routed event already marked handled, but only through code. For more information about routed events in Silverlight, see Events Overview for Silverlight.

WPF introduced the concept of commanding. Only a few Silverlight classes in Silverlight 5 support the commanding infrastructure. ButtonBase and Hyperlink provide Command and CommandParameter properties. Silverlight does not provide command libraries as part of the runtime, or specific built-in behaviors of the core types or Silverlight SDK controls that interface with the commands. However, the Silverlight input system interprets the commands. The design intention is that the command implementations exist as a component of the data source itself, as part of a view model relationship. Commands are hooked to the Command properties through binding to the same source that generates the UI-visible data.

WPF and Silverlight have similar property systems that both use the concept of a dependency property. You can define a custom dependency property, but there are some important differences. Most notably, Silverlight does not have separate registration methods for read-only dependency properties, does not use metadata flags, and does not have an explicit coercion system or callback. For more information, see Custom Dependency Objects and Dependency Properties.

Silverlight does not include the concept of separate runtime-accessible visual and logical trees that are included in WPF. Also, Silverlight have the LogicalTreeHelper API. Silverlight does provide the VisualTreeHelper class in case you need to navigate the rendered objects in the object tree. For more information, see Silverlight Object Trees.

In WPF, all visual elements derive from the Visual class, which does not exist in Silverlight. However, a subset of Visual-analogous capabilities exist in other Silverlight base classes.

Silverlight does not include Freezable objects in its object model. For more information, see Freezable Objects Overview in the WPF documentation.

Silverlight 5 supports some of the multitouch API from WPF. However, the Silverlight 5 client as a whole is registered for touch messages, and the multitouch events are handled through a client-level Touch service class. In contrast, WPF has element-level support for multitouch events on its UIElement class. Also, the Silverlight 5 version of multitouch does not provide native gesture handling or manipulation/inertia handling. If you need this multitouch support in Silverlight 5, you have to handle the raw messages and implement this functionality yourself.

Note:
Silverlight for Windows Phone does use manipulation and gestures in its input model. For more information, see Input in Silverlight for Windows Phone.

Both WPF and Silverlight allow subpixel rendering. However, in some cases, subpixel rendering can result in blurry text, images, and other displayed objects when antialiasing is applied to the object. For more information about subpixel rendering, see Pixel Snapping in WPF Applications in the WPF documentation. WPF handles subpixel rendering issues by using a feature called pixel snapping, which snaps lines to the nearest device pixel. Silverlight introduces the concept of layout rounding, which rounds object dimensions to the nearest whole integer. This feature can be turned off by setting the UseLayoutRounding flag to false. For more information, see Layout Rounding. Silverlight also has a TextHintingMode property for overriding certain text display optimizations so that they work better if the text is being repositioned or animated dynamically.

The printing support in Silverlight is designed to allow users to print a UIElement that is contained in the Silverlight application, which varies substantially from the document-focused printing in WPF. For more information about printing support in Silverlight see, Printing. For more information about printing with WPF, see Printing Overview in the WPF documentation.

There are a few XAML processing differences between WPF and Silverlight. For more information about these differences, see XAML Processing Differences Between Silverlight Versions and WPF.

WPF has an XBAP deployment model that runs in a browser. Silverlight uses a different deployment technique where an application can be configured to run outside the browser after being installed from a host Web page. In addition, the out-of-browser application can request elevated permissions, and can thus access features that the default sandbox of a WPF XBAP cannot. For more information, see Out-of-Browser Support.

Silverlight and WPF both use resource dictionaries as a technique for sharing resource content, but there are some implementation differences. The following is a list of the most notable issues.

• Silverlight has a different list of which types are shareable.

• UIElement derived classes are never usable as resources, even if they are only referenced once. This is enforced at run time.

• Silverlight does not have a FindResource API. Instead, you use the ResourceDictionary indexer against a specific ResourceDictionary instance. The behavior difference here is that using the indexer does not step through the entire resource lookup sequence as is used for load-time XAML, it only checks that instance.

• For XAML references to resources, only StaticResource is available, because Silverlight does not support DynamicResource.

• Silverlight supports an x:Name on a ResourceDictionary item and can use x:Name as a substitute for x:Key. WPF does not support this behavior.

For more information, see Resource Dictionaries.

Silverlight uses a slightly different behavior for how it interprets coordinates and measurement units for layout and display APIs.

• WPF supports a measurement system that by default is based on Device Independent Pixel (DIP) units. Silverlight supports a measurement system that is always based on pixel units.

• WPF measurement properties specified in XAML can include a unit measure string suffix that changes the interpretation of the preceding numeric value. For example, in WPF you can specify 10cm, where the cm indicates centimeter units. As part of XAML processing in WPF, that value is converted to a device independent pixel value at run time. Silverlight does not support this behavior; any XAML that includes a unit suffix such as px,pt,in or cm is invalid in Silverlight and throws a parse error. Silverlight measurements are always pixel units.

• Certain measurement properties in both WPF and Silverlight support setting a value "Auto" if specified in XAML, or Double.NaN if specified in code. The behavior is the same in either WPF or Silverlight. The difference is that WPF uses an explicit LengthConverter to enable the XAML usage. Silverlight uses a native XAML conversion behavior. Properties that can accept "Auto" for XAML in Silverlight are specifically indicated as part of their XAML syntax section in reference documentation.

• WPF has a theoretically unbounded coordinate system. Silverlight has a bounded coordinate system. The maximum value for a coordinate component in Silverlight is approximately +32678. APIs that represent a Silverlight coordinate might throw a native-level error or raise an exception if this maximum value is exceeded. This is true even for values that might be temporary and not intended for the final rendering value. 32678 is well beyond the maximum screen size, so this should only be an issue if you are performing math or applying transforms to coordinate values.

Silverlight introduces the Deep Zoom feature, which allows zooming in and out of high-resolution images or collections of images. For more information, see Deep Zoom.