Silverlight uses a particular implementation of a XAML parser, with that parser being part of the Silverlight core install. In some cases, the parsing behavior differs from the parsing behavior in Windows Presentation Foundation (WPF), which also has a particular implementation. Processing differences listed here might be useful if you are migrating XAML that was originally produced for WPF UI and intend to use similar UI definitions for Silverlight.
XAML Processing Differences Between Silverlight and WPF
.gif) Important Note: |
|---|
All material in this section applies specifically to Silverlight version 3 and its implementation of the XAML parser provided with that release. Also, 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. |
.gif) Note: |
|---|
Material in this section applies to the Silverlight XAML parser that is present in the core Silverlight installation. Tools and development environments that can load XAML, such as Microsoft Expression Design or Microsoft Expression Blend, as well as the XAML markup compile pass for MSBUILD, may have different behavior. In some cases, a tool or development environment might block loading XAML that the Silverlight parser would accept, so relying on the parser behavior exclusively might not be practical during the end-to-end process of developing an application for Silverlight. |
Except where noted below, the Silverlight parser follows the recently published XAML language specification and has the same behavior as the WPF parser.
Namespaces
Most tools from Silverlight 2 onward will generate XAML for Silverlight with the http://schemas.microsoft.com/winfx/2006/xaml/presentation namespace. However, Silverlight supports http://schemas.microsoft.com/client/2007 as an equivalent legacy XAML namespace (this was the XAML namespace used for Silverlight 1.0).
Silverlight imposes the following restrictions on setting xmlns values:
The root element must always contain a default xmlns declaration; no implicit value is assumed.
Any default xmlns declaration (whether on the root element or not) must be http://schemas.microsoft.com/winfx/2006/xaml/presentation, http://schemas.microsoft.com/client/2007, or (rarely used) the XPS namespace (http://schemas.microsoft.com/xps/2005/06). Exception: The Silverlight application manifest is technically XAML, but its root typically is the Deployment object, which generally must use the default XAML namespace xmlns="http://schemas.microsoft.com/client/2007/deployment" in order to be resolved.
Silverlight imposes the following restrictions on mapping assembly and namespace for xmlns values:
The assembly must be either mscorlib (to support the sys: case) or the name of an assembly in the XAP file. (The assembly cannot be an assembly that is not deployed with the XAP package.)
The assembly name in the mapping cannot include ".dll" at the end of the name.
Constructs
The only supported xml: construct in Silverlight is xml:lang. (Note: xml:space is permitted as an attribute for Silverlight XAML parsing, but space preservation behavior in Silverlight never uses xml:space as a determinant).
The only supported XAML namespace (http://schemas.microsoft.com/winfx/2006/xaml) constructs in Silverlight are: x:Null, x:Name, x:Key, and x:Class. Notable omissions here are x:Array, x:Code, x:Type, and code access modifiers such as x:Subclass.
The only supported constructs from a mapped System namespace, mscorlib assembly combination in Silverlight (typically mapped as sys:) are sys:Double, sys:String, and sys:Int32. (The intention here is to use the "primitives" defined there as object elements, typically for use as a resource in a resource dictionary.)
The only supported markup compatibility construct in Silverlight (from the XML namespace http://schemas.openxmlformats.org/markup-compatibility/2006, which is typically mapped to mc:) is mc:Ignorable. mc:Ignorable may appear only as an attribute, not as an element, and may only appear on the root element.
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
There is limited support for markup extensions in Silverlight. The only markup extensions are x:Null, StaticResource, Binding, RelativeSource, and TemplateBinding. There is no public MarkupExtension class in the hierarchy, which means there is no support for custom markup extensions. Except for Binding and RelativeSource, the markup extensions do not have corresponding classes to support parallel markup extension/code scenarios.
Except for Binding, markup extensions may be used only in attribute syntax, not object element syntax. Except for Binding, the constructor parameters to those markup extensions may not be named. For example, {StaticResource aKey} works, but {StaticResource ResourceKey=aKey} does not work.
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.
In terms of XAML behavior, there is limited support in Silverlight for object elements that are not a DependencyObject:
Object elements that are not a DependencyObject do not support x:Name.
Certain objects (in particular many of Silverlight's structures) support an initialization text syntax, which resembles object element syntax with inner text. Examples include Color and FontFamily. The initialization text usage is sometimes necessary in order to use these types of objects as resource dictionary items, because the Silverlight XAML parser blocks assigning property values of some classes and structures as attributes.
The Name attribute is valid on all DependencyObject subclasses in Silverlight and is treated the same as x:Name. This is true despite there being no Name property defined in the backing object model at this particular point. The parser will also modify the value of the Name property for both FrameworkElement and Inline subclasses, which have a defined Name in the object model.
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.
With the exceptions of TextBlock and Run, object elements in Silverlight cannot contain XML text nodes as an implicit way to set their text-type content properties. For example, <Button> hello world </Button> is not allowed in Silverlight XAML, you would have to specify <Button Content="hello world".../>. Again, note that there are some syntaxes (such as for Color) that might resemble object element with inner text syntax, but they are technically an initialization text syntax, which supplies the string to type-convert for initialization sas inner text.
Other Behavior
FrameworkTemplate and subclasses support 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.
UserControl..::.Content is a protected property rather than a public property. As an internal parser behavior, the Silverlight parser can set UserControl..::.Content for a UserControl with its XAML content, so long as a value for x:Class is specified.
Most Silverlight structures do not support property values of the structure type to be set as attributes on the object element. The exceptions are Matrix, Matrix3D, and Point, which do support object element syntax and then setting the structure properties as attributes. Other than these exceptions, use either the attribute form for structure-type values of properties in Silverlight 3 as is documented on each structure reference page, or declare object elements with initialization text to set the structure's values.
Measurement properties of type Double can process the string "Auto" to mean the value Double..::.NaN, as a native parsing behavior that does not involve a type converter.
Concepts