情報
要求されたトピックは次のとおりです。しかし、このトピックはこのライブラリには含まれていません。

Silverlight バージョン間の XAML 処理の相違

Silverlight

アプリケーションが依存する Silverlight のバージョンに応じて、別々の XAML パーサーが使用されます。 まだ Silverlight 3 を対象にしているアプリケーションに対して、違いが最も明確になります。 この場合、XAML は異なる解析コードパスで解析されます。 互換性を確保するために、Silverlight 5 Beta コア ライブラリにはこの 2 種類のパーサーが収められています。 Silverlight 3 を対象にコンパイルされたアプリケーションは、Silverlight 3 専用の XAML パーサーを使用します。 Silverlight 4 および Silverlight 5 Beta を対象にコンパイルされたアプリケーションは、Silverlight 4 専用の XAML パーサーを使用します。 Silverlight 4 と Silverlight 5 Beta の間には XAML の他の違いもありますが、大きな違いではありません。

次のセクションでは、まだ Silverlight 3 を対象にしている Silverlight アプリケーションにだけ存在する XAML 構文の違いについて説明します。

構文の違い

以降のセクションでは、Silverlight 3 と Silverlight 4 で処理が異なる XAML 言語形式と構文の違いについて説明します。

混合コンテンツとプロパティ要素

Silverlight 3 では、XAML の混合コンテンツとプロパティ要素がサポートされます。 Silverlight 4 以降の XAML および [MS-XAML] では、これがサポートされません。 たとえば、次の XAML コードは、Silverlight 3 では解析できますが、Silverlight 4 以降では解析できません。

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

推論によるプロパティ要素 xmlns

Silverlight 3 では、親オブジェクト要素の XAML 名前空間情報を指定しないプロパティ要素が含まれる XAML コードが許容されます。 Silverlight 4 以降の XAML では、このような XAML コードは許容されず、XAML 解析例外がスローされます。 たとえば、次の XAML は、Silverlight 3 では有効ですが、Silverlight 4 以降では無効です。

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

不適切な属性 xmlns

Silverlight 3 では、解決されない属性に対する xmlns を持つ XAML が許容される場合があります。そのような場合、Silverlight 3 では、オブジェクト要素 xmlns へのフォールバックが使用されます。

Silverlight 4 以降では、このような XAML コードは許容されず、XAML 解析例外がスローされます。

読み取り専用のコレクションのコレクション オブジェクトの明示的なオブジェクト要素

Silverlight 3 の場合、読み取り専用のコレクション プロパティに、コレクション型のオブジェクト要素を格納することができます。 これは、オブジェクト要素によって型のインスタンスがインスタンス化されるという一般原則に違反しており、読み取り専用コレクションでは無効です。 この場合、Silverlight 3 では解析例外がスローされます。 たとえば、次のコードは、Silverlight 3 では有効ですが、Silverlight 4 以降では無効です。

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

コンテンツ プロパティの文字列コンテンツ

Silverlight 3 では、数少ないオブジェクト (特に TextBlock および Run) に対してのみ、オブジェクト要素の文字列コンテンツがサポートされます。 他のオブジェクトでは、コンテンツ文字列がサポートされません。 たとえば、Silverlight 3 では <Button>Hello</Button> が無効なので、代わりに <Button Content="Hello" /> フォームを使用する必要があります Silverlight 4 以降では、通常この制限はありません。 ただし、すべてのコントロールでコンテンツ文字列を受け取ることができるわけではありません。 特定のコントロールでコンテンツ文字列を受け取ることができるかどうかは、オブジェクト モデルに依存します。これは、対応するプロパティを XAML コンテンツ文字列として構文ごとに設定できるかどうかということよりも重要な考慮事項です。

XAML 初期化テキストは文字列コンテンツの形式に似ていますが、これは実際には XAML コンテンツ プロパティに設定される文字列ではありません。 詳細については、XAML の概要 のトピックを参照してください。

空白の処理

Silverlight 3 では、CRLF が有意と見なされる状況でも、広い範囲で空白がそのまま扱われていました。 そのため、不要な空白が表示されるのを避けるために CRLF が省略されたファイル形式 XAML になることがありましたが、編集環境でユーザーがこれを判読することはできませんでした。 Silverlight 4 以降では、WPF に似た、より直感的な有意の空白モデルを使用しています。 このモデルでは、ほとんどの場合、ファイル形式空白が折りたたまれますが、特定の CLR 属性を持つコンテナーは例外で、すべての空白が有意なものとして扱われます。 この空白モデルの採用により、XAML コードの書式指定を可能にする空白を編集環境で使用できるようになりました。 さらに Silverlight 4 以降では、空白の表示に関する問題をより適切に制御するためのテキスト要素も用意されています。

メモ メモ :

Silverlight の XAML 解析の属性として xml:space を使用することはできますが、Silverlight 3 における空白の保持動作の決定要因として、xml:space が使用されることはありません。 これに対し、Silverlight 4 以降では xml:space="preserve" が考慮され、この値を使用して既定の空白折りたたみ動作がオーバーライドされます。

XAML 言語のエンティティ

Silverlight 3 では、XAML 言語の XAML 名前空間 (x:) に存在しないエンティティは無視されます Silverlight 4 以降では、そのようなエンティティが Silverlight における XAML 言語の定義に含まれていない場合、解析例外がスローされます。 (注意: x:Uid は、Silverlight 3 でも Silverlight 4 以降でも許容されます。 ただし、Silverlight の API およびビヘイビアーから x:Uid に書き込んだり、読み取ったりすることはできません。)

x:Key スコープ

Silverlight 3 では、ResourceDictionary のスコープにおいてのみ x:Key の使用が許可されます。Silverlight 4 以降では、バッキング型が IDictionary を実装する任意の要素の使用方法において、x:Key もサポートされます。

x:Name の動作と XAML 名前空間

Silverlight 3 の場合、DependencyObject 以外の XAML オブジェクト要素では、構文レベルで x:Name がサポートされません。 一方、Silverlight 4 以降ではこの構文がサポートされます。ただし、そのオブジェクトを XAML 名前空間に追加することができない可能性があります。

マークアップ拡張

Silverlight 3 の場合、Binding を除き、マークアップ拡張機能は、オブジェクト要素構文ではなく属性構文内でのみ使用できます。 Binding を除き、これらのマークアップ拡張機能のコンストラクター パラメーターで名前付きパラメーターを使用することはできません。 たとえば、{StaticResource aKey} は有効ですが、{StaticResource ResourceKey=aKey} は有効ではありません。

XAML 名前空間

Silverlight 3 では、Silverlight 4 以降と異なり、XAML 名前空間の宣言に対して次の制限があります。

  • ルート要素は、既定の名前空間宣言を必ず含んでいる必要があります。 暗黙の値は想定されません。

  • すべての既定の名前空間宣言は、ルート要素上であるかどうかに関係なく、http://schemas.microsoft.com/winfx/2006/xaml/presentationhttp://schemas.microsoft.com/client/2007、または XPS 名前空間 (http://schemas.microsoft.com/xps/2005/06) である必要があります (ただし、XPS 名前空間が使用されることはほとんどありません)。

  • Silverlight のアプリケーション マニフェストは技術的には XAML ですが、そのルートは通常、Deployment オブジェクトです。一般に、このオブジェクトを解決するためには、既定の XAML 名前空間 xmlns="http://schemas.microsoft.com/client/2007/deployment" を使用する必要があります。

  • Silverlight 4 以降にも同様の制限がありますが、それは Page ビルド アクションの XAML マークアップ コンパイル動作にのみ適用されるものであり、実行時に使用される XAML パーサーで一般的に適用されるものではありません。

マークアップ コンパイルまたは部分クラスの動作

Silverlight 3 で x:Class を使用するとき、ルート要素のサブクラスにプロパティを設定すると、そのプロパティがルート タグに存在しなくてもサブクラス内のプロパティに解決されるため、動作は有効になります。 Silverlight 4 以降では、この場合、例外がスローされます。 次のコード例は、Silverlight 3 では動作しますが、Silverlight 4 以降では例外がスローされます。

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

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

Silverlight 3 の場合、XAML のルート タグの種類と分離コード クラスの種類が異なっていても、エラーは発生しません。 Silverlight 4 以降では、パーサーにより例外が正しくスローされます。 次のコード例は、Silverlight 3 では動作しますが、Silverlight 4 以降では例外がスローされます。

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

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

解析と検索の動作

以降のセクションでは、Silverlight 3 と Silverlight 4 以降で処理が異なる解析評価と基になるコードの検索の動作について説明します。

重複するプロパティ セット

環境によっては、Silverlight 3 の XAML で同じプロパティを複数回設定できます (排他的な非ネイティブ実装による、コア プロパティ以外のプロパティの場合)。 Silverlight 4 の場合、これは決して許容されず、XAML 解析例外がスローされます。

列挙値の評価

Silverlight 3 が初期化テキスト値を使用して列挙値を解析する際、整数値が生成されます。 一方、Silverlight 4 以降では、列挙値が生成されます。 この違いが現れるのは、分離コードの値にアクセスする場合と、評価済み列挙値を UI で表示する場合です。しかし、後者の場合、UI での表示は適切な方法ではありません。

TypeConverter または Storyboard の型チェック

Silverlight 3 では、Storyboard 以外の表示状態と、TypeConverter 以外の TypeConverterAttribute 属性付きクラスが許容されます。 どちらも実行時に問題となる可能性がありますが、XAML でのマークアップ コンパイルと読み込みに対して許容されていました。 Silverlight 4 以降では、どちらの場合も例外がスローされます。

添付プロパティのサポート

Silverlight 3 の場合、静的な setter しか持たない添付プロパティを XAML から使用できました。 Silverlight 4 以降では、静的な getter と静的な setter の両方が必要です。 さらに、Silverlight 3 には、添付プロパティを依存関係プロパティのバッキングを使用して実装するという特定の要件があります。 Silverlight 4 以降では、この制限はありません。

バインディング属性からの StaticResource の検索

Silverlight 3 では、Binding のサブプロパティで実行する StaticResource 参照が失敗する場合でも、XAML 解析中にはエラーが発生しません。 バインディングは、そのサブプロパティが設定されていないかのように動作します。 一般的に、これは StaticResource の通常の動作ではないため、バインディングのデバッグに支障が生じる可能性があります。 Silverlight 4 以降では、Binding のサブプロパティで StaticResource 参照が失敗する場合、解析例外がスローされます。

システムのプリミティブ

マップ対象の System 名前空間でサポートされる構成体である、Silverlight 3 の mscorlib アセンブリの組み合わせ (一般的に sys: としてマップされます) は、sys:Doublesys:Stringsys:Boolean、および sys:Int32 のみです。 ここでの意図は、そこに定義されている "プリミティブ" をオブジェクト要素 (通常はリソース ディクショナリ内のリソース用) として使用することです。

テンプレートの動作

  • Silverlight 3 の場合、CLR アクセサーを持たないプロパティに対する TemplateBinding が可能です。 Silverlight 4 以降の場合、この動作はブロックされます。

  • Silverlight 3 の場合、解析不能なテンプレートもリソースとして使用できます。 Silverlight 4 以降の場合、この動作はブロックされます。

  • Setter.Property および TemplateBinding のプロパティ名は、Silverlight 3 では大文字と小文字が区別されませんが、Silverlight 4 以降では区別して処理されます。

  • Silverlight 3 の場合、アニメーションまたはストーリーボードで解決されない、または名前を間違えた TemplateBinding は、単にプロパティを設定しませんでした。 Silverlight 4 以降では、例外が正しくスローされます。

  • Silverlight 3 では、基本クラスを対象とする TargetType を使用して ControlTemplate を作成し、そのサブクラスのメンバーに対して TemplateBinding を使用しても、TemplateBinding ではそのプロパティが擬似的に動的な動作として解決されます。 Silverlight 4 以降ではこれがエラーとして扱われるため、デザイナーはこれをキャッチして、適切に例外をスローできます。 これは、明示的な TargetType がない場合 (TargetType="Control" と等価です) も該当します。

  • Silverlight 3 では、静的リソースに対する前方参照がテンプレートのどこで定義されていても読み込みに失敗しませんでした。 Silverlight 4 以降では、この場合、例外がスローされます。 この場合における実行時の Silverlight 3 の動作は不確定です。Silverlight 4 以降では、テンプレートの作成時点で、予測できないこの実行時動作のキャッチが試みられます。 静的リソースに対する前方参照を行う Silverlight 3 テンプレートは、他の要因によってアプリケーションの有効期間とタイミングが変化して不確定な動作が変わらない限り、それまで実行していた処理を続行します。

UserControl の動作

  • UserControl.Content は、Silverlight 3 では保護されているプロパティですが、Silverlight 4 以降ではパブリック プロパティです。 パーサーの内部的な動作として、Silverlight 3 XAML パーサー (およびマークアップ コンパイラ) は、x:Class の値が指定されている限り、UserControl に対する UserControl.Content をその XAML コンテンツで設定できます。

Silverlight と .NET Framework XAML Services

Silverlight 4 以降、Silverlight XAML パーサーは、.NET Framework の一部として System.Xaml アセンブリに定義されている .NET Framework XAML サービス API と互換性があります。 Silverlight XAML パーサーそのものは独立しています。Silverlight コア ライブラリは、System.Xaml アセンブリなど、クライアント側の .NET Framework のどの部分にも依存していません。 ただし、Silverlight 3 ランタイムとその XAML パーサーは、.NET Framework XAML サービス API と対話可能ではありません。

Silverlight 5 Beta と Silverlight 4 には、XAML に関してわずかな相違点があります。 これらは一般的に、重大な変更ではなく、比較的小さな変更です。

XAML オブジェクトと構造体の属性構文

Silverlight 4 では、構造体を XAML 内のオブジェクト要素として宣言するために初期化構文を使用する必要がある、少数の構造体がありました。 これは、目標が構造体をリソース ディクショナリからの共有値となるように定義することであり、構造体を x:Key でキー設定できるようにするためにオブジェクト要素が要件となる場合、実際的な考慮事項となりました。 対象の構造は、CornerRadiusRectSizeThickness です。 Silverlight 5 Beta では、これらの構造体をオブジェクト要素として宣言し、構造体の書き込み可能なプロパティに属性として値を割り当てることができます。

Silverlight XAML と WPF XAML の違いについては、「Silverlight バージョンと WPF との間の XAML 処理の相違」で解説しています。 Silverlight 3 XAML と WPF XAML を比較する場合、このトピックに加えて「Silverlight バージョンと WPF との間の XAML 処理の相違」にも目を通し、その違いについて検討する必要があります。

コミュニティの追加

表示:
© 2014 Microsoft