2012-09-12 18 views
6

私はWPFとSilverlightの両方で使用されるコードを記述しています。 C#では条件付きコンパイルに"#if SILVERLIGHT"を使用できます。T4を使用したWPFおよびSilverlight用の統合XAML?

ただし、一部の属性が互換性がないため、XAMLでは完全に異なるXAMLファイルを使用する必要があります。 XAMLファイルは99%のようなもので、同期させるのは面倒です。

私はT4テンプレートに変換したいと思いますので、私はのようなものを行うことができます:ClipsToBounds()は、WPFとSilverlightの異なるテキストを生成

<SomeControl <#=ClipsToBounds()#> /> 

。要件は次のとおりです。

  • インテリセンスプロジェクトは自己完結することとVisual Studioの株式バージョンで動作しなければならない
  • ビルド時に生成されたXAML
  • テンプレートでの作業中:様々なのSDKのインストールおよびサードパーティの編集者 受け入れ可能
  • テンプレート実行の結果をソース管理にするべきではありません。 -

XAMLファイルのcustom toolMSBuild:Compile to TextTemplatingFileGeneratorから変更できますが、Intellisenseを失うことはありません。ただし、結果として生じるテンプレートは設計時に生成されます。ビルド時に生成されたことは大きな苦痛のようです。

誰もこの種のセットアップで成功した経験はありますか?

+0

ポータブルクラスライブラリをオプションで使用していませんか? –

+0

ポータブルクラスライブラリは共有された非UIコードの問題を解決します。ビューではなくMVVMを使用する場合、ViewModelレイヤに適しているはずです。 –

答えて

0

プラットフォーム全体の一般的な動作を持つ汎用ユーザーコントロールのみをPCLに配置できますが、プラットフォームごとに個別のxamlビューを作成することをお勧めします。

0

誰もテンプレートベースのソリューションを希望どおりに提案しているようではないので、私はSL/WPFの両方を対象としたプロジェクトで作業している経験をいくつか共有します。多くの人が、2つの完全に別々のXAMLファイルを使用することを提案します。これは、プラットフォームごとに異なるビューであり、さまざまな点でこれが「純粋な」ものです。しかし、重複を排除し、2つのターゲットが乖離するリスクを減らしたい場合は、XAMLファイルを共有することをお勧めします(単純なプロジェクトリンクを使用)。

いくつかの一般的な非互換性があります。

  • コントロールが異なる名前空間の両方のプラットフォームに存在する - 独自のバージョンをサブクラス化しているを参照してください。
  • プラットフォーム間でスタイルなどが異なる必要があります。共通のリソース辞書、プラットフォームごとの違い、キーによる参照などがあります。
  • コントロールは実質的に異なり、1つのプラットフォームにのみ存在します。独自のラッパーコントロールを導入します(「欠落した」ケースでは実質的な実装が必要な場合があります)。
  • 基本的なプロパティや機能がありません - 接続された動作(たとえば、ClipsToBoundsの例がhereなど)で何かをハッキングすることがよくあります。
関連する問題