Bagikan melalui

  • Artikel

XAML Processing Differences Between Silverlight Versions

Microsoft Silverlight will reach end of support after October 2021. Learn more.

Silverlight potentially uses different XAML parsers depending on which Silverlight version your application. The differences are most pronounced for applications that still target Silverlight 3. In this case, the XAML is parsed by a different parsing codepath. The two parsers exist side-by-side in Silverlight 5 core libraries for compatibility. 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 and Silverlight 5 use the Silverlight 4-specific XAML parser. Other XAML differences exist between Silverlight 4 and Silverlight 5, but these differences are relatively minor.

Silverlight Version 3

The following sections describe XAML syntax differences that only exist for Silverlight applications that still target Silverlight 3.

Syntax Variations

The following sections describe XAML language forms and syntax variations that have different handling in Silverlight 3 and Silverlight 4.

Mixed Content and Property Elements

Silverlight 3 supports mixed content and property elements in XAML. Silverlight 4 and later XAML and [MS-XAML] does not. For example, the following XAML can parse in Silverlight 3, but not in Silverlight 4 and later:

<Grid x:Name="LayoutRoot">
    <TextBlock>
        <TextBlock.Text>
            <Binding Path="Text" ElementName="tb" />
        </TextBlock.Text>
    </TextBlock>
    <Grid.RowDefinitions>
        <RowDefinition />
        <RowDefinition />
    </Grid.RowDefinitions>
    <TextBox x:Name="tb" Grid.Row="1" /><!--this is a second content set, invalid in v4-->
</Grid>

Inferred Property Element xmlns

Silverlight 3 is tolerant of XAML that has property elements that do not specify the XAML namespace information of their parent object element. Silverlight 4 and later XAML is not tolerant of this and throws a XAML parse exception. For example, the following XAML is valid in Silverlight 3, but invalid in Silverlight 4 and later:

<controls:WrapPanel Width="100" Height="100"

xmlns:controls="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls">

<WrapPanel.Background><!--needs prefix...-->

<SolidColorBrush Color="Red" />

</WrapPanel.Background>

</controls:WrapPanel>

Spurious Attribute xmlns

In some cases, Silverlight 3 is tolerant of XAML that has xmlns on attributes that do not resolve. In those cases, Silverlight 3 uses a fallback to the object element xmlns.

Silverlight 4 and later is not tolerant of this and throws a XAML parse exception.

Explicit Object Element of a Read-Only Collection's Collection Object

In Silverlight 3, read-only collection properties are permitted to contain an object element for the collection type. This violates the general principle that an object element instantiates an instance of the type, which would not be valid for a read-only collection. Silverlight 3 throws parse exceptions for this case. For example, the following is valid in Silverlight 3, but invalid in Silverlight 4 and later:

<DoubleAnimationUsingKeyFrames>
  <DoubleKeyFrameCollection>
    <DiscreteDoubleKeyFrame Value="100" KeyTime="0:0:2" />
    <DiscreteDoubleKeyFrame Value="400" KeyTime="0:0:4" />
  </DoubleKeyFrameCollection>
</DoubleAnimationUsingKeyFrames>

String Content for Content Properties

Silverlight 3 supports string content of an object element only for a few objects, notably TextBlock and Run. Other objects do not support content strings. For example, <Button>Hello</Button> is invalid in Silverlight 3, and must instead use the form <Button Content="Hello" />. Silverlight 4 and later typically does not have this restriction. However, do not interpret this to mean that any control can accept a content string. Whether a particular control can accept a content string depends on its object model, which is a more important consideration than whether setting the corresponding property as a XAML content string is possible per the syntax.

Note that XAML initialization text resembles a string content form, but this is not truly a string being set to the XAML content property. For more information, see XAML Overview.

Whitespace Handling

Silverlight 3 treats whitespace more literally in a wider range, including some cases where CLRF is considered significant. This sometimes led to file-format XAML with omitted CRLF in order to avoid unwanted whitespace in the presentation, but which was not human-readable in editing environments. Silverlight 4 and later uses a more intuitive significant-whitespace model that is similar to WPF. This model collapses file-formatting whitespace in most cases, with exception of certain CLR-attributed containers that treat all whitespace as significant. This whitespace model gives editing environments greater freedom to introduce whitespace that can improve XAML code formatting. Also, Silverlight 4 and later has text elements that permit even greater control over whitespace presentation issues.

NoteNote:

xml:space is permitted as an attribute for Silverlight XAML parsing, but space preservation behavior in Silverlight 3 never uses xml:space as a determinant. In contrast, Silverlight 4 and later respects xml:space="preserve", and uses this value to override its default whitespace collapsing behavior.

XAML Language Entities

In Silverlight 3, nonexistent entities from the XAML language XAML namespace (x:) are ignored. Silverlight 4 and later throws parse exceptions in this case if Silverlight does not have that entity in its definition of the XAML language. (Note: x:Uid is permitted in Silverlight 3 as well as Silverlight 4 and later. However, no Silverlight API or behavior either reads or writes to x:Uid.)

x:Key Scope

Silverlight 3 only permits x:Key usage in the scope of a ResourceDictionary. Silverlight 4 and later also supports x:Key within any element usage where the backing type implements IDictionary.

x:Name Behavior / XAML Namescopes

XAML object elements that are not a DependencyObject do not support x:Name at the syntax level in Silverlight 3. In contrast, Silverlight 4 and later accept the syntax, but may not be able to add the object to the XAML namespace.

Markup Extensions

Except for Binding, markup extensions in Silverlight 3 may be used only in attribute syntax, not object element syntax. Except for Binding, the constructor parameters to those markup extensions cannot use the named parameter syntax. For example, {StaticResource aKey} works, but {StaticResource ResourceKey=aKey} does not work.

XAML Namespaces

Silverlight 3 imposes the following restrictions on XAML namespace declarations that differ from Silverlight 4 and later:

  • The root element must always contain a default namespace declaration. No implicit value is assumed.

  • Any default namespace declaration (whether on the root element or not) must be https://schemas.microsoft.com/winfx/2006/xaml/presentation, https://schemas.microsoft.com/client/2007, or the XPS namespace (https://schemas.microsoft.com/xps/2005/06), which is rarely used.

  • The Silverlight application manifest is technically XAML, but its root typically is the Deployment object, which generally must use the default XAML namespace xmlns="https://schemas.microsoft.com/client/2007/deployment" in order to be resolved.

  • Silverlight 4 and later may also have similar restrictions, but these would exist only in the XAML markup compile behavior for the Page build action, not generally in the XAML parser used at run time.

Markup Compile or Partial Class Behavior

When using x:Class, Silverlight 3 enabled a behavior whereby if you set a property on the subclass of the root element, the property is resolved to the property on the subclass even though it does not exist on the root tag. Silverlight 4 and later throws exceptions in this case. The following is an example that works in Silverlight 3, but throws an exception in Silverlight 4 and later.

public class MyPage : UserControl
{
    public int Value { get; set; }
}

<UserControl x:Class="SilverlightApplication1.MyPage " ... Value="17" >
</UserControl>

In Silverlight 3, a mismatch between the type of the root tag in XAML and the type of the class in the code-behind was accepted without error. In Silverlight 4 and later, the parser correctly throws an exception. The following is an example that works in Silverlight 3, but throws an exception in Silverlight 4 and later.

namespace MyNS
{
    public class Page : Canvas { etc. etc. }
}

<UserControl x:Name="parentCanvas" x:Class=" MyNS.Page" ... />

Parsing and Lookup Behaviors

The following sections describe parsing evaluations and lookups into the backing code that have different handling in Silverlight 3 and Silverlight 4 and later.

Duplicate Property Sets

In some circumstances, you can set the same property multiple times in Silverlight 3 XAML, if it is a non-core property with exclusively non-native implementation. Silverlight 4 never allows this and will throw a XAML parse exception.

Evaluating Enumeration Values

When Silverlight 3 parses an enumeration with an initialization text value, it produces an integer value. Silverlight 4 and later will instead produce the enumeration value. This is relevant if you access the values in the code-behind, or present evaluated enumerations in the UI. However, the latter is generally not a good UI practice.

Type Checking for TypeConverters or Storyboards

Silverlight 3 accepts visual states that are not a Storyboard, and TypeConverterAttribute attributed classes that are not a TypeConverter. Both of these are likely to cause run-time problems, but were accepted in XAML for markup compile and load. Silverlight 4 and later throws an exception for these cases.

Backing for Attached Properties

In Silverlight 3, attached properties with only a static setter could be used from XAML. In Silverlight 4 and later, they require a static getter and a static setter. Also, Silverlight 3 has a specific requirement that the attached property be implemented with dependency property backing. Silverlight 4 and later does not have this restriction.

StaticResource Lookup From Binding Attributes

In Silverlight 3, subproperties of a Binding that make a StaticResource reference that fails do not raise any errors during XAML parsing. The binding acts as if that subproperty is not set. This is not typical StaticResource behavior, and can interfere with debugging of a binding. Silverlight 4 and later will throw a parse exception for subproperties of a Binding that make a StaticResource reference that fails.

System Primitives

The only supported constructs from a mapped System namespace, mscorlib assembly combination in Silverlight 3 (typically mapped as sys:) are sys:Double, sys:String, sys:Boolean, 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.)

Template Behavior

  • In Silverlight 3, TemplateBinding to a property that does not have a CLR accessor is permitted. Silverlight 4 and later blocks this behavior.

  • In Silverlight 3, a non-parseable template is allowed to exist as a resource. Silverlight 4 and later blocks this behavior.

  • Property names in Setter.Property and TemplateBinding are case-insensitive in Silverlight 3, but are processed case-sensitive in Silverlight 4 and later.

  • In Silverlight 3, a non-resolving or mistyped TemplateBinding in an animation or storyboard simply did not set the property. In Silverlight 4 and later, an exception is correctly thrown.

  • In Silverlight 3, if you create a ControlTemplate with a TargetType targeting a base class, and use a TemplateBinding to a member of the subclass, the TemplateBinding might still resolve that property as a quasi-dynamic behavior. Silverlight 4 and later treats this as an error so that designers can catch this, and throws an exception appropriately. This includes cases with no explicit TargetType, which is equivalent to TargetType="Control".

  • In Silverlight 3, a forward reference to a static resource defined elsewhere in a template does not fail to load. Silverlight 4 and later throws an exception in this case. Note that the Silverlight 3 behavior for this at run time is indeterminate. Silverlight 4 and later attempts to catch this unpredictable run-time behavior at the time that you produce the templates. A Silverlight 3 template that makes a forward reference to a static resource will continue to work if it worked before, unless other factors change application lifetime and timing and thus change the indeterminate behavior.

UserControl Behavior

  • UserControl.Content is a protected property in Silverlight 3, but a public property in Silverlight 4 and later. As an internal parser behavior, the Silverlight 3 XAML parser (and markup compiler) can set UserControl.Content for a UserControl with its XAML content, as long as a value for x:Class is specified.

Silverlight and .NET Framework XAML Services

Starting with Silverlight 4, the Silverlight XAML parser is compatible with .NET Framework XAML Services APIs that are defined in the System.Xaml assembly as part of the .NET Framework. The Silverlight XAML parser itself is self-contained. Silverlight core libraries have no dependency on the System.Xaml assembly or any other part of the full .NET Framework on the client. However, the Silverlight 3 runtime and its XAML parser are not capable of interacting with .NET Framework XAML Services APIs.

Silverlight Version 4

There are a small number of XAML differences between Silverlight 5 and Silverlight 4. These are generally not breaking changes, and constitute relatively trivial enabling changes.

XAML Object and Attribute Syntax for Structures

In Silverlight 4, there were a small number of structures where you needed to use initialization syntax in order to declare a structure as an object element in XAML. This became a practical consideration if the goal was to define a structure to be a shared value from a resource dictionary, and the object element was a requirement so that the structure could be keyed with x:Key. The structures in question are: CornerRadius, Rect, Size, Thickness. In Silverlight 5, it is possible to declare these structures as object elements, and to assign values to the structures' writeable properties as attributes.

Silverlight XAML and WPF XAML

Differences between Silverlight XAML and WPF XAML are described in the topic XAML Processing Differences Between Silverlight Versions and WPF. If you are comparing Silverlight 3 XAML and WPF XAML, you should read both XAML Processing Differences Between Silverlight Versions and WPF as well as this topic, and consider both sets of differences.