XAML Processing Differences Between Silverlight and WPF

Silverlight uses a particular implementation of a XAML parser, with that parser being part of the client libraries for Silverlight. 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

Important Note:
All material in this section applies specifically to Silverlight version 2 and its implementation of the XAML parser provided with that release.

Note:
Material in this section applies to the Silverlight XAML parser that is present in the client libraries. 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.

Note:

Material in this section applies to the Silverlight XAML parser that is present in the client libraries. 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

Silverlight supports http://schemas.microsoft.com/client/2007 as well as http://schemas.microsoft.com/winfx/2006/xaml/presentation as its client namespace. (http://schemas.microsoft.com/client/2007 is most commonly used in practice.)
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/client/2007, http://schemas.microsoft.com/winfx/2006/xaml/presentation, or (rarely used) the XPS namespace.
- A non-default xmlns declaration may not use one of the above URIs. In other words, xmlns:otherns="http://schemas.microsoft.com/client/2007" is not allowed.
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 a DLL from the Silverlight core installation, and cannot be entirely external.)
- The assembly name cannot include ".dll" at the end of the name.

Constructs

The only supported xml: construct in Silverlight is xml:lang.
The only supported x: constructs in Silverlight are: x:Null, x:Name, x:Key, and x:Class. Notable omissions here are x:Array, x:Code, and code access modifiers such as x:Subclass.
The only supported sys: constructs in Silverlight are sys:Double, sys:String, and sys:int32. (A sys: construct means that you have mapped the prefix sys: to the System namespace and the mscorlib assembly, with the intention of using the "primitives" defined there as object elements.)
The only supported mc: construct in Silverlight is mc:Ignorable, and it may appear only as an attribute, not as an element, and only on the root element.

XAML Language Intrinsics

There is limited support for markup extensions in Silverlight. The only markup extensions are x:Type (generally used implicitly for properties that are of type Type), x:Null, StaticResource, Binding, and TemplateBinding. There is no public MarkupExtension class in the hierarchy, which means there is no support for custom markup extensions. Except for Binding, 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), and 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.
- Only the following non-DependencyObject classes are supported: classes defined in an assembly that is downloaded with the application (not in the core Silverlight installation); classes mapped by the sys: namespace; Color and FontFamily.
The Name attribute is valid on all DependencyObject subclasses in Silverlight and is treated the same as x:Name. For subclasses of FrameworkElement, the parser will modify the value of the Name property even though it has no public (code) setter.
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: Inside generic.xaml only, both Name / x:Name and x:Key are optional on Style elements if the TargetType attribute is specified.
With the exceptions of TextBlock and Run, object elements in Silverlight may not contain XML text nodes as an implicit way to set their text-type content properties. For instance, <Button> hello world </Button> is not allowed in Silverlight XAML.

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 this content, so long as a value for x:Class is specified.