今井正明（カイゼンコンセプトの著者）
クロスプラットフォームは、市場のアプリケーションの主要な要件の1つです。 最新のプログラミング言語のほとんどはクロスプラットフォームですが、ほとんどすべての言語で、開発者はソフトウェアと1つまたは別のシステムとの互換性の問題に直面しています。 特定のオペレーティングシステム用にプロジェクトをコンパイルするか、インタープリター言語の実行環境用のプロジェクトを開発する必要があります。
.NETランタイムを使用すると、中間コード（バイトコード）を使用してクロスプラットフォームソフトウェアを開発できます。 私の意見では、.NETはクロスプラットフォームソフトウェアを開発するための最良のソリューションのようです。 ただし、他のすべてと同様に、このソリューションには欠点があります。 これらは、.NET Standardを排除するように設計されています。
どうでしたか
いくつかの.NETプラットフォームを検討してください。 まず、.NET FrameworkはWindowsでのみ使用可能であり、他のオペレーティングシステムでランタイムを実行することはできません。 次に、Mono / Xamarinは、Mac、IOS、Androidをサポートする真のクロスプラットフォームソリューションです。 欠点の1つは、.NET Frameworkとの完全な互換性の欠如です。その結果、Mono / Xamarinに移植するときにプロジェクトからコードの一部をカットする必要があります。 最近登場した別のプラットフォームは.NET Coreです。 Windows、Linux、Mac、Docker用のサーバーベースのクロスプラットフォームソフトウェアを開発および実行できます。
オペレーティングシステムの種類と範囲が広くても、開発されたプログラムはクロスプラットフォームではない場合があります。 プラットフォーム自体は完全に互換性がありません。 解決策があります-すべてのプラットフォームと完全に互換性のあるカーネルを開発し、不足している部分を追加します。 そして、互換性のあるものとそうでないものを判断する方法は？ 残っているのは、これらのプラットフォームのドキュメントとAPIの研究に時間を費やすことだけです。
ポータブルクラスライブラリ-祖先.Net標準ライブラリ
Portable Class Library（PCL）は、クロスプラットフォームのライブラリ開発ツールです。 プロジェクトを作成するときは、プラットフォームのリストを選択して開発を開始する必要があります。 当初、PCLはWindowsとWindows Phoneのみをサポートしていました。 マイクロソフトはすぐにXamarinを買収し、すぐにXamarinのサポートがPCLに導入されました。 .NET Coreの開発に伴い、PCLでのこのプラットフォームのサポートも登場しました。 プラットフォームが増えているため、プラットフォームの共通部分であるPCLは小さくなってきています。 マイクロソフトは、代替ソリューションを提供することを決定しました。
新しい.NET標準ライブラリプラットフォーム
Microsoftが新しいプラットフォーム.NET標準ライブラリを追加 最初に考えたのは、「プロジェクトがこのプラットフォームでも動作するように、ドキュメントをさらに読む必要がある」ということです。 結局のところ、これはそうではありません。 .NET標準ライブラリは、他のプラットフォームの共通インターフェース（.NET Core、.NET Framework、Mono / Xamarinなど）の仕様の正式なセットです。 .NET標準仕様を満たすライブラリは、さまざまな.NETプラットフォームで使用できます。 実際、Standardはさまざまなランタイム環境でライブラリを使用できることを保証し、.NETエコシステムにこれまで欠けていた汎用性をもたらします。
.NET Standardは、アプリケーションのアーキテクチャを変更し、一般的な.NETインフラストラクチャとエンドプラットフォームの間のレイヤーとして位置付けられています。
クロスプラットフォームアプリケーションコアの割り当てがはるかに簡単になりました。 カーネルが標準で構築されていれば十分です。 また、他の.NET標準ライブラリをこのカーネルで使用できます。 新しいレイヤーは、将来のプラットフォームのキュレーターです。 新しいプラットフォームは、PCLの場合のように、.NET標準に準拠する必要があります。
各プラットフォームの独自の標準
.NET標準ライブラリはバージョンによって異なります。各バージョンは次のものと完全に互換性があります（PCLについては言えません）。 下位互換性はありません。 より高いバージョンを選択すると、ライブラリの開発に使用できるAPIが増えます。 ただし、これは開発中のライブラリをサポートするプラットフォームが少なくなることを意味します。 次の表は、.NET Standardのさまざまなバージョンを示しています（テーブルは.NET Standardのリリースバージョン用にコンパイルされています）。
| ターゲットプラットフォーム名 | エイリアス | |||||||
|---|---|---|---|---|---|---|---|---|
| .NET標準 | ネットスタンダード | 1.0 | 1.1 | 1.2 | 1.3 | 1.4 | 1.5 | 1.6 |
| .NET Core | netcoreapp | → | → | → | → | → | → | 1.0 |
| .NET Framework | ネット | → | 4.5 | 4.5.2
4.5.1 | 4.6 | 4.6.1 | 4.6.2 | 4.6.3 |
| ユニバーサルWindowsプラットフォーム | うん | → | → | → | → | 10.0 | ||
| 窓 | 勝つ | → | 8.0 | 8.1 | ||||
| Windows Phone | wpa | → | → | 8.1 | ||||
| Windows Phone Silverlight | wp | 8.1
8.0 | ||||||
| モノ/ Xamarinプラットフォーム | → | → | → | → | → | → | * | |
| モノ | → | → | * |
最初の行は、.NET標準ライブラリのバージョン番号を示しています。 次の各行には、適切な標準を使用して記述されたライブラリを使用できるプラットフォームとバージョンが含まれています。 矢印は、このバージョンのStandardと同じ行の次のセルとの互換性を示しています。
例：
- ライブラリが.NET Standard 1.3の仕様を満たしている場合は、.NET Framework 4.6（以降）、. NET Core、Universal Windows Platform 10（UWP）、およびMono / Xamarinのプラットフォームでのみ使用できます。
- ライブラリが標準1.3で記述されている場合、標準バージョン1.0、1.1、1.2、1.3を使用して記述された他のライブラリを使用できます。
.NET標準ライブラリについて
.NET標準ライブラリは、抽象セットの形式で表すことができます。以下のそれぞれには、以前のものが含まれ、独自の何かを追加し、.NETプラットフォームのコードをさらにカバーします。 したがって、バージョン番号が大きくなるとサイズが大きくなります。
新しいバージョンごとに、アプリケーションの機能コアは成長しますが、「フル」プラットフォームの多くの機能は利用できません。 他のセットの画像を見てみましょう：.NET Framework、.NET Core、Mono / Xamarin：
同じバージョンの.NET Standardは、これらのプラットフォーム上の同一のコードセットをカバーしています。 そして、完全に交差点内にあります。 アプリケーションの中心は中央の円の内側になります。 アプリケーション自体は、他のプラットフォームのサポートを実装するために、3つの部分に分割する方が適切です。 したがって、完成した製品は3つのプラットフォームといくつかのオペレーティングシステムですぐに動作します。
.NET標準ライブラリを使用する長所：
- クロスプラットフォーム、複数の.NETプラットフォーム、複数のオペレーティングシステム。
- コードのサポート-リリース後のプロジェクトの保守が容易になり、移植せずに新しい機能が追加されます。
- 保証-.NET標準のNugetの次のライブラリは、いくつかのオペレーティングシステムで確実に動作します。
.NET標準ライブラリを使用することの短所：
- すぐに使える機能制限-.NET Standardは進化し続けています。
- 既存のプロジェクトを.NET標準に移植することの難しさ。
おわりに
.NET標準ライブラリは、不便なポータブルクラスライブラリの優れた代替品です。 標準ライブラリは、クロスプラットフォームの点ではるかに優れています。 クロスプラットフォームアプリケーションコアを簡単に選択したり、.NET Standard仕様を満たすクロスプラットフォームライブラリを開発したりできるようになりました。 次に、必要なオペレーティングシステムに必要なインターフェイスを記述し、完成品を取得します。