今日、多くの開発者が、Silverlightと.Netランタイムの両方を実行するコードを作成しています。 良い例は、Silverlightを使用してクライアント側で最初にチェックし、次に.Netを使用してサーバー側でデータをチェックする場合のデータのチェックです。 最近まで、同じコードを異なるランタイム（Silverlightと.Net）のアセンブリにコンパイルする必要がありました。 このモデルは実行可能ですが、完璧ではありません！
この新しい機能を「アセンブリポータビリティ機能」と呼びました。これにより、Silverlightと.Netの間で記述されたコードを移植できます。
注意したいのですが、この機能
は 、Silverlightおよび.Netランタイムでのコード実行の基本的なメカニズムを
変更するものではありません ！ 2つのランタイムに共通のAPIを使用するコードを作成する場合、同じアセンブリセットを使用してアプリケーションを作成できます。 しかし、どのAPIが一般的かをどのようにして知るのでしょうか？
Silverlightと.Netの間で移植可能な5つのキービルドをインストールしました。 （Silverlight UIは確かに移植性がありません。SilverlightUIとWPFには根本的な違いがあります。）
いつものように、どのシナリオを選択するかという大きな選択に直面しました。 その結果、Silverlightから.Netへのアセンブリの移植を許可することが決定されました。 この決定の動機は、Silverlightが.Netアセンブリのサブセットを実装するという事実であり、このサブセットを使用するアセンブリが.Netで機能することが明らかになりました。
もう1つの重大な問題は、Silverlightと.Netの両方で安全に動作するアセンブリの選択です。 移植性が役立つシナリオのほとんどを検討し、最も基本的なシナリオから始めることにしました。 その結果、.Net 4およびSilverlight 4では、さまざまな興味深いシナリオを作成できると思われる低レベルアセンブリのセットのみを選択しました。
SL 4および.NET 4については、以下を公開しました。
- Mscorlib
- システム
- System.Core
- System.ComponentModel.Composition
- Microsoft.VisualBasic
Visual Studio 2010の例プロジェクトを作成する
.NetでのSilverlightアセンブリの使用
.Netにはまだ利用できない多くのタイプがあることにもう一度注意したい