特定のプラットフォームのタイプの可用性の背後にある決定は何ですか？

Question

私はPCLで遊ぶことに決め、クラスライブラリをPCLに変換しました。

驚くことではありませんが、欠落しているタイプのエラーが多数表示されます。

しかし、私が本当に混乱していたのは、何が欠けているかによってです。

CancelEventArgsクラスがサポートされていますが、CancelEventHandlerはサポートされていません。

これは、特定のタイプを含まない単純な機会または意図的な決定ですか？ プラットフォームの設計に関する有益な情報を、タイプの存在または不在という事実から抽出できますか？

は、私は明確にしましょう：

すぎて、プラットフォーム固有の概念が削除されたとき、私は例を理解することができます。

しかし、PCLのことはあまり明らかではありません。

私は自分自身を他人よりも賢明ではないと考えていたので、私は明確な理由を探します。

一般的なタイプをできるだけ大きく設定することは、プラットフォーム間の移行を容易にすることです。 Eric Lippert氏は、すべての機能が価値/経費の観点から正当化されなければならないと述べています。したがって、私は大きな型式の値を過大評価するか、可搬性を実装することの難しさを過小評価します。コード分​​析を実行する特定のイベントとしては

---

EventHandler<TEventArgs>

に別の同様のquestionをgenreicバージョンを使用する音recomendationを与えました。

Answer 1

かなり機械的なプロセスです。 PCLプロジェクト用に選択した各プラットフォームで使用可能な一連のタイプを単に交差させます。いずれかのターゲットで利用できないすべてのタイプを削除します。あなたが何を残しているかはあなたが使用できるものです。

CancelEventHandlerは、タイプを詳しく調べるまで、奇妙な省略のように見えるかもしれません。これには属性があり、HostProtectionAttributeは広くサポートされていません。

だから、PCLはちょうどあなたが "ああ撃つ"を避けるのに役立ちます！あなたがクラスライブラリの型の使用を強くお約束した瞬間です。後であなたのライブラリを別のターゲット上で動作させることはできません。これは非常に醜いので、コードの作成とテストに多くの時間を費やす可能性があります。その問題について早期に頭を悩ますことで、痛みや苦しみの莫大な量を節約できます。

普通のクラスライブラリプロジェクトをPCLプロジェクトに変換して間違った方法で実際には動作しません。これはすばらしい「オハイオ州シュート」ですが、PCLの限界とは関係ありませんが、少なくともあなたは何に集中すべきかを知り、どのくらいの仕事があなたより先んでいるかについて十分な印象を与えます。

Answer 2

this blog postの「なぜAPIは移植性がないのですか」のセクションでこれを少し説明します。

ポータブルクラスライブラリで作業していたとき、.NET 4、Silverlight、およびWindows Phone 7が終了したか、ほとんど終了したので、より移植性の高いAPIをサポートするために多くの変更を加えることはできませんでした。 .NET 4.5では、。NET for Windows Storeアプリケーション、およびWindows Phone 8では、PCLをサポートするためにもっと多くのことができました。 NET for Windowsのほとんどすべての.NETタイプストアアプリは、.NET 4.5および.NET for Windows StoreアプリケーションをターゲットとするPCLで利用できます。 Windows Phone 8はこれらのAPIのほとんどもサポートしており、最大の違いはHttpClientで、これはfilled with a NuGet packageです。

基本的に、新しいプラットフォームをターゲットにすると、より多くのタイプが移植可能になり、時間が経つにつれてより良いものになるはずです。