XAML Processing Differences Between Silverlight Versions

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>

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>

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.

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>

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.

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.

Note:
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.

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.

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.

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.

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.

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.

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.

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.

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.)

• 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.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.