PCL は実際に何を解決するのでしょうか。クロスプラットフォームの型に制限するだけなら、なぜ Microsoft はこれを IDE を介して標準の .NET ライブラリの機能として作成しなかったのですか?
基本的に、いくつかの POCO オブジェクトを含む .NET ライブラリを簡単にコンパイルし、Silverlight、WPF、および Windows ストア アプリでその DLL を参照できます。再コンパイルや問題は発生しません。標準の .NET ライブラリでは機能せず、PCL で機能するコードの難しい例はありますか?
ああ、明らかに標準の .NET ライブラリで機能するものがいくつかあることは知っていますが、それについては心配していません...私の質問は次のとおりだと思います。
ポータブル クラス ライブラリでコンパイルされ、まったく同じコードが .NET ライブラリにあると正しく機能しないコードはありますか?
2つのこと：
まず、複数のプラットフォームで動作するライブラリを作成することを意図している場合、(TypeLoadException または MissingMethodException などを介して) すべてのプラットフォームで使用できない API を誤って使用したことを実行時に知りたくありません。 . そのため、Portable Class Libraries は、対象とするすべてのプラットフォームでサポートされている API に対してのみ IntelliSense を提供し、そのセット以外のすべてに対してビルド エラーが発生します。
第 2 に、すべてのプラットフォームで利用可能な API のみを使用する .NET Framework ライブラリを作成した場合、作成された DLL は、他のプラットフォーム (Windows Phone や Silverlight など) では、それらのプラットフォーム用のライブラリとしてコンパイルしないと動作しません。それは妥当な予想ですが、過去にはそうではありませんでした。ポータブル クラス ライブラリは、私たちがそれを機能させる方法です (実際、Windows ストア アプリ用のクラス ライブラリを作成し、.NET Framework と WP8 で利用可能な API のみを使用する場合、結果として得られるバイナリは両方で機能します。これらのプラットフォームの変更なし)。
コード自体についてはあまり心配しませんが、次のことを試してみて、ポータブル クラス ライブラリが役立つ理由を確認してください。
次のエラー メッセージが表示されます。
Silverlight ランタイムに対してビルドされていないため、Demo.Utils.dll への参照を追加することはできません。Silverlight プロジェクトは、Silverlight アセンブリでのみ機能します。
それ自体は、ポータブル クラス ライブラリが非常に優れている理由のほんの一部です。難しいのは、コードをプラットフォームにとらわれないように適応させようとすることです。これは簡単に思えますが、思ったほど簡単ではありません。最初にフォルダーからファイルを読み取ろうとして、PCL では許可されていないことに気付いたFileInfoときはイライラしますが、Microsoft からのガイダンスは、プラットフォームの依存関係を抽象化し、インターフェイスを実装するクラスを挿入することです。実際に世話をします。実際、これに関する素晴らしい記事があります。
もう 1 つの有用な記事では、PCL のセットアップ方法の内部動作について説明しています。この記事は、 PCL が複数のプラットフォームをターゲットにできる理由を理解するのに役立ちます。https://www.simple-talk.com/blogs/2013/04/19/inside-portable-class-libraries/
What is Portable Class Library で簡単な YouTube ビデオを作成しました。ここから見ることができますhttp://www.youtube.com/watch?v=DcBfjdDHlxo
クラス ライブラリ プロジェクトを作成する上で重要なのは、再利用性です。現在、.NET アプリケーション内だけでなく、.NET アプリケーション間ではなく、さまざまな種類の .NET アプリケーション間でこの再利用性が必要です。現在、さまざまな種類の .NET アプリケーションとは、WPF、Windows、Silver light、Windows phone などを意味します。
現在、これらのアプリケーションの種類はそれぞれ異なり、.NET フレームワークが少し異なります。
たとえば、シルバー ライト アプリケーションで単純な「クラス プロジェクト」を参照しようとすると、以下のエラーで終了します。そこで、ポータブル クラス ライブラリが役立ちます。ポータブル クラスを作成することで、あらゆる種類の .NET プロジェクト タイプで参照できます。
ポータブル クラス ライブラリは実際に何を解決しますか?
最終的には多くのことを解決します！(Java のように、しかし今世紀に)
ポータブル クラス ライブラリでコンパイルされ、まったく同じコードが .NET ライブラリにあると正しく機能しないコードはありますか?
原則的には違うと思いますが、逆ではありませんか？
しかし、敬意を表したいと思いますが、あなたは実際には要点を見逃しているかもしれません
コードのコピー/貼り付け、プロジェクトのクローン作成、コードのリンク、条件付きコンパイラ ディレクティブ (T4 テンプレートも?) について考えてみると、最終的な結果は参照DLL Hellと不要な複雑さ、ボイラープレート、冗長性 (あまりエレガントではありませんか?) になります。
バイナリの非互換性に対する回避策ではありませんか?
非常に初期の段階ですが、Xamarin と Mono が pcl のサポートに取り組んでいるのを見ると (既に部分的にサポートしています)、素晴らしい方向性だと思います。(TypeSafe万歳!)
PCL は、Windows ボックスから C# アーミーを解放することもできます
（ただし、これはすべて私の意見です）