XAML Processing Differences Between Silverlight Versions and WPF
Microsoft Silverlight will reach end of support after October 2021. Learn more.
Silverlight includes a XAML parser that is part of the Silverlight core install. Silverlight uses different XAML parsers depending on whether your application targets Silverlight 3 or more recent Silverlight versions. In addition to Silverlight version differences, the XAML parsing behavior in Silverlight sometimes differs from the parsing behavior in Windows Presentation Foundation (WPF). WPF has its own XAML parser. This topic describes the XAML processing differences between Silverlight and WPF, which is useful if you are migrating XAML written for WPF to Silverlight.
Silverlight XAML Parsers and Silverlight Versions
Silverlight 4 introduced a XAML parser that is closer to the WPF XAML parser implementation. However, applications exist that might still target Silverlight 3. To support these applications, Silverlight includes a legacy XAML parsing codepath in the Silverlight client runtime. Applications that are compiled for and target Silverlight 3 use the Silverlight 3-specific XAML parser. Applications that are compiled for and target Silverlight 4 or later use the main XAML parser.
If you are maintaining a Silverlight application that targets Silverlight 3, the XAML differences between Silverlight versions is documented in another topic. For more information, see XAML Processing Differences Between Silverlight Versions.
.gif "Important note") Important Note: |
|---|
Processing XAML for the JavaScript API in Silverlight is not described here, because the JavaScript-specific XAML behaviors in Silverlight are not relevant for comparison with WPF or for version differences in Silverlight. |
.gif "Note") Note: |
|---|
This section applies to the Silverlight XAML parsers that are present in the core Silverlight installation. Tools and development environments that can load XAML, such as Microsoft Expression Blend, as well as the XAML markup compile pass in MSBUILD for Silverlight, may have different behavior. In some cases, particularly if you are still using Visual Studio 2008 or targeting Silverlight 3, a tool or development environment might block loading XAML that a Silverlight parser would accept. Therefore relying on the parser behavior exclusively might not be practical during the end-to-end process of developing an application for Silverlight. |
XAML Processing Differences In Silverlight (4 and later) Versus WPF
Except where noted in the following sections, the Silverlight 4 and later XAML parser and the XAML language support follow the XAML language specification [MS-XAML] and has the same behavior as the WPF parser.
Namespaces
The Silverlight XAML markup compiler has restrictions on which namespaces can be used as the default XAML namespace, and on requirement for a default namespace. The default XAML namespace must be one of the following:
(The latter namespace is supported for legacy reasons; new applications should use https://schemas.microsoft.com/winfx/2006/xaml/presentation).
However, these restrictions are only for XAML markup compile from the Page build action. For loose XAML (such as a ResourceDictionary with the Content build action, or input for the XamlReader.Load method) the XAML parser in the core libraries supports assignment of any namespace to be the default, or no default.
Silverlight imposes the following restrictions on mapping assembly and namespace for XAML namespaces:
The referenced assembly must be the name of an assembly in the XAP file, or of a Silverlight core assembly such as mscorlib. (The assembly cannot be an assembly that is not deployed with the XAP package.) This is part of how Silverlight manages security and permissions for client code.
The assembly name in the mapping cannot include ".dll" at the end of the name.
Constructs
The only supported XAML namespace (https://schemas.microsoft.com/winfx/2006/xaml) constructs in Silverlight are: x:Null, x:Name, x:Key, and x:Class. Notable omissions here that exist in WPF or [MS-XAML] are x:Array, x:Code, x:Type, and code access modifiers, such as x:Subclass. x:Uid is permitted but ignored by the parser itself, and has no API connection point in Silverlight.
mc:Ignorable (from the XML namespace https://schemas.openxmlformats.org/markup-compatibility/2006) is permitted as an attribute on the root element, but ignored.
Silverlight does not guarantee to preserve CDATA. (The main scenario for CDATA in WPF is x:Code, which Silverlight does not support.)
XAML Language Intrinsics
The built-in Silverlight markup extensions are as follows: x:Null, StaticResource, Binding, RelativeSource, and TemplateBinding. Except for Binding and RelativeSource, the markup extensions do not have corresponding classes to support parallel markup extension/run-time scenarios.
Silverlight does not support adding "Extension" to the end of a markup extension name as an alternate usage. For example, {x:Null} works, but {x:NullExtension} does not. This is not necessarily a XAML behavior; it is a Silverlight implementation detail.
Object elements inside a ResourceDictionary in Silverlight may have an x:Name instead of or in addition to an x:Key. If x:Key is not specified, the x:Name is used as the key. (Exception: both Name / x:Name and x:Key are optional on Style elements if the TargetType attribute is specified. For more information, see Resource Dictionaries.
Other Behavior
FrameworkTemplate and derived classes support XAML content even though they have no ContentPropertyAttribute, or seemingly any settable property in the object model. Template creation in general is an internal parser behavior in Silverlight. In WPF, there is a public VisualTree content property, which does not exist in Silverlight.
The Color structure does not support setting its Byte properties (A, R, G, B) as XAML attributes on a <Color /> object element. This is because Byte does not have native type-conversion support in Silverlight XAML.
Measurement properties of type Double can process the string "Auto" to evaluate to Double.NaN. This is a native parsing behavior that does not involve a type converter. However, this behavior is not extensible to custom properties of type Double, it only applies to Silverlight defined APIs.
XAML Processing Differences Between Silverlight 3 and Silverlight 4
The XAML processing differences between Silverlight 3 and Silverlight 4 are described in a separate topic. For more information, see XAML Processing Differences Between Silverlight Versions. Generally, the differences between Silverlight 3 and Silverlight 4 are representative of Silverlight 3 using behavior that may be unexpected based on either [MS-XAML] or the WPF XAML behavior.