寧Zhangさんのブログ

はじめ

あなたがSilverlightコントロールを記述する場合、次の2つの単純な理由のために、あまりにも、コントロールのデザイン時のアセンブリを書くことを検討する必要があります。

• 開発者の生産性：Visual StudioやブレンドのようなツールなしでSilverlight開発を想像してみて！ カスタムコントロールでは、Visual Studioで、コントロールのデザイン時の経験の多くを提供したり、自分でブレンドする必要がある場合があります。
• 設計者：ブレンドのようなXAMLとツールは、開発者とデザイナーが連携して動作可能に。 Silverlightコントロールの主要な設計基準は、設計者はコードを一行も書かずにそれらを使用できることを確認することです。

デザイン時の操作は、通常（ただし、これらに限定されない）、次のとおりです。

1. カテゴリ、infotip、カスタムプロパティ/コレクション/バインディングエディタなどのプロパティウィンドウのメタデータ、
2. デザインサーフェイス、初期化子のような、装飾、コンテキストメニュー、アダプタ等のためのメタデータ
3. アイコンのようなツールボックスの統合、、コントロールの登録
4. コー​​ドエディタのインテリセンス

インテリセンス（参照ください除いて、Silverlightのコントロールのリッチインテリセンスを追加 ）し、コントロールの登録（参照くださいVisual StudioやBlendでのSilverlightコントロールを登録する ）、上記の設計時の経験は通常、デザイン時のアセンブリを介して配信されます。 下記の私は複雑さと柔軟性で、設計時のエクスペリエンスを提供するの様々なアプローチを説明し、徐々にデザイン時のアセンブリの命名規則の一部をご紹介。

ランタイムアセンブリのみ

デザイン時のエクスペリエンスを実現する最も簡単な方法は、設計時のメタデータは次のように、あまりにも、実行時 ​​に意味がある場合は特に、ランタイムアセンブリに設計時のコードをパッケージ化することですTypeConverterAttributeを 。

このアプローチの長所と短所：

• プロ：シンプル
  • 個別の設計時アセンブリない、シンプルなセットアップ
  • デザイン時の属性は、メンテナンスしやすく、実行時にコードで直接指定されています
• 欠点：実行時および設計時のコードの密結合
  • 実行時のために無駄なデザイン時のコードのPERFの劣化
  • 設計時の依存関係は、（MWDsおよび他のVS /ブレンドアセンブリのような）不必要に実行時にドラッグさ
  • 独立して実行時または設計時にサービスを提供することはできません
  • 複数の設計者をサポートできない（VS2008/Blend2とVS2010/Blend3両方のような）

設計時アセンブリが​​Silverlightの型への参照で、実際に。NETアセンブリなので短所は、Silverlight用の特に悪いです。 ミキシングSilverlightと。NETアセンブリは困難と混乱、そして微妙なバグにつながる可能性がありますすることができます。 また、Silverlightアプリケーションは、主にWebアプリケーションですので、ダウンロードサイズとパフォーマンスが特に重要である。 確かに効果がないSilverlightアプリケーションの。NETアセンブリにドラッグする。 それのための強力な正当な理由がある場合を除きので、このアプローチは非常に、推奨されていません。

共有設計時アセンブリ

ように革命的なステップは前方に、設計時および実行時コードを分離放出し、別のアセンブリでそれらを処理することです。 これは可能性のすべての種類を開きます。 もちろん、我々は、ランタイムアセンブリに不必要な依存関係やPERF劣化を導入することなく、それらに対応するランタイムのアセンブリへのデザイン時のアセンブリをリンクする方法が必要です。 したがって、命名規則： ランタイムアセンブリFoo.dllは、Silverlightプロジェクトで参照されている場合、設計者は （Visual Studioとブレンドのような） 最初のアイコンのようなデザイン時の情報をロードしようとする （別の命名規則を経由して、参照してツールボックスを追加する方法自分のSilverlightコントロールのアイコン ）と、設計時のメタデータ（のようなインターフェースを介してIRegisterMetadata VS2008とBlend2のための、またはVS2010とBlend3用IProvideAttributeTable参照してください。 すべての設計者のためのSilverlightのデザインタイムを作成する方法：Visual Studio 2008で、Blend 2では、Blend 3の、とVisual Studio 2010の ランタイムアセンブリから）、それはその後Foo.dllと同じディレクトリにある名前のFoo.Design.dllによってデザイン時のアセンブリを探します。見つかった場合は、設計者は、Fooから設計時の情報をロードしようとします。同様に。Design.dll。

デザイナー特定のデザイン時のアセンブリ

ブレンドは、設計者のために主にある間、Visual Studioは、開発者向けの主になるので、設計時の経験の要件が異なります。 つの共有デザイン時のアセンブリ内のすべてのデザイン時のコードを置くことはタイトな設計者の間のカップリングが導入されています。 命名規則が強化されるように： ランタイムアセンブリのFoo.dllのために、すべての設計者によって読み込まれる共有のデザイン時のアセンブリのFoo.Design.dllがあり、それぞれの設計者はまたFoo.VisualStudioように、独自のデザイン時のアセンブリをロードしようとします。 Visual Studioで、ブレンド用Foo.Expression.Design.dll用Design.dll。 デザイナー、特定のデザイン時のアセンブリは、共有のデザイン時のアセンブリの後にロードされます。サードパーティの設計者は独自のデザイナー、特定のデザイン時のアセンブリを定義することができます。 Silverlightツールキット2008年12月のリリースではこの命名規則を使用している。 参照してくださいSilverlightツールキットのデザインタイム機能とSilverlightツールキットの設計時の機能の実装詳細については、を。

デザインサブフォルダ

したがって、Visual Studioとブレンドの両方をサポートするために、それぞれのランタイムアセンブリが同じディレクトリ内に、3つのデザイン時のアセンブリがあり、パッケージには、（SilverlightのSDKなどのSilverlightツールキット ）は、通常いくつかのランタイムアセンブリが含まれています。 ので、ディレクトリには、少し混みあってくる。 マイナーな改善は、デザインのサブフォルダの下に、設計時のアセンブリを配置することです。 命名規則はさらに高められるように： 設計者は（Visual Studioまたはブレンドのような）ランタイムアセンブリと同じディレクトリ内の対応するデザイン時のアセンブリを見つけることができない場合が存在する場合、それは、デザインのサブフォルダから探そうとします。

MWDsの複数のバージョンをサポート

設計時間をの上に構築されているデザイナの機能拡張フレームワーク Microsoft.Windows.Design.Extensibility.dllとMicrosoft.Windows.Design.Interaction.dllのようないくつかのDLLで構成されています、。 我々は、通常総称MWDsとしてそれらを呼ぶ。 人生をより面白くするために、時には私たちはバージョン3.5、VS2010とバージョン4.0のMWD Blend3使用をMWD VS2008とBlend2を使用するように、拡張性のフレームワークに重大な変更を導入しなければならない、と彼らは互換性がありません。 あなたがランタイムアセンブリfoo.dllを持っていて、ユーザーがVS2008とVS2010の両方で、それに対して開発できるようにしたいのであれば、あなたは、デザイン時のアセンブリの2つのセットを提供する必要があります：一つのセットはv3.5 MWDsに対してビルドと使用VS2008、およびMW​​DとVS2010で使用されているv4.0のに対して構築された別のセットで。 VS2010用のがレバレッジVS2010によって公開される新しい機能をするためにいくつかの新しいコードがあるかもしれないが、デザイン時のアセンブリの二組は、おそらく、共通のコードがたくさんある。 デザイン時のアセンブリが​​名前によってロードされていて、同じ名前を持つ2つのファイルを持つことができないので、命名規則はまだ再び強化さSO：

ランタイムアセンブリFoo.dllのために、共有のデザイン時のアセンブリがFoo.Design *. dllの名前は、Visual Studioの特定のデザイン時のアセンブリは、Foo.VisualStudio.Design *. dllの名前が付けられ、ブレンド、特定のデザイン時のアセンブリはFooという名前です。Expression.Design *. *はゼロまたはそれ以上の有効な文字がファイル名には可能なDLL、。 デザイナーが（Visual Studioまたはブレンドのような）デザイン時のアセンブリをロードし、いくつかの命名規則に合うようにしようとすると、ゼロまたは1がロードされます。

• デザイン時のアセンブリによって参照されるMWDバージョンは設計者のMWDバージョンとは異なるメジャーバージョン番号を持っている場合、デザイン時のアセンブリがロードされ、バイパスされません。
• 複数のデザイン時のアセンブリは、設計者のMWDバージョンと互換性がある場合、デザイナーはより小さいか、デザイナーのMWDバージョンに等しい最高MWDのバージョンに対してコンパイルつをロードします。

Silverlight 3のツールキット2009年10月リリースでは、 VS2008とBlend3/VS2010の両方をサポートするために、この命名規則を使用しています。 参照してくださいSilverlightのデザインタイムを：ツールキット2009年10月リリースの更新 、 すべてのデザイナーのためのSilverlightのデザインタイムを作成する方法：Visual Studio 2008で、Blend 2では、ブレンド3、およびVisual Studio 2010 、および拡張シリーズ- WPF＆Silverlightのデザインタイムコードの共有-パートIの詳細。

WPFとSilverlightの両方をサポート

WPFとSilverlightは非常にひどく似ているので、さらに人生を複雑にするには、一度それを書くと、WPFとSilverlightの両方で実行しようとする誘惑に駆られることがあります。 あなただけではない。 ソースコードおよび/またはSilverlightとWPF間でのバイナリを共有する方法について多くの記事があります。 我々はあまりにもデザイン時のアセンブリに対してそのようなことをしたいのですが、つまりは、WPFとSilverlightのコントロールの両方に同じデザイン時のアセンブリを持っている。 一つのアプローチは、設計時のアセンブリのプラットフォームに依存しないのを最大限に活用、およびリミットプラットフォーム固有の（WPFまたはSilverlight）コードと小さなプラットフォーム固有のアセンブリへの参照にすることです。 Silverlight 3のSDK GDR 2は （あまりにも自動的にVS2010がインストールされている）DataGridのこのアプローチを使用するデザイナー（SDKディレクトリにあるSystem.Windows.Controls.Data.VisualStudio.Design.4.0.Silverlight.dllがある）。 参照してくださいWPF＆Silverlightのデザインタイムコードの共有- -パートI拡張シリーズの詳細については、を。

最後のWINS

クラスまたはそのメンバーのための同じ設計時のメタデータは、共有のデザイン時のアセンブリが​​必要に応じてそれを上書きするデフォルトの/共通動作し、設計者特定のデザイン時のアセンブリを指定することができる複数のデザイン時のアセンブリで複数回指定できます。 同じ設計時のメタデータは、単一のデザイン時のアセンブリ（参照してください内で複数回指定することができますSilverlightツールキットの設計時の機能の実装例として、 のDescriptionAttributeクラスまたはそのプロパティにはAddDescriptions、AddAttributesとAddTablesの方法で追加することができますが） 。 だから我々はメタデータが勝つかを知る必要があります。 最も単純で論理設計は最後の勝利です。 これは常に主に真ではないです。 時には、結果は同じ設計時のメタデータが複数回指定されている場合に非決定論的であるが、異なる値を持つことができる。

フィードバック

設計時には簡単に聞こえるが、悪魔は細部​​に宿る！ フィードバックはいつでも歓迎されています。 私はあなたが設計時間の経験とデザイナの機能拡張フレームワークの両方に、あなたが作るためにしたいのか要求/改善、に実行するかを問題に知らせてください。 ありがとう！