かつて、.NET Frameworkとして知られている単一の.NETがあった。.NETアプリケーションを作成する場合は、.NET Frameworkがターゲットとなり、それはシンプルであった。数年後、.NET種のカンブリア爆発が起こった（「.NETの爆発」と呼ぶ）。 .NETの派生には、.NET Framework Client Profile、.NET Compact Framework、.NET Micro Framework、Windows Runtime、Universal Windows Platform、Mono、Xamarin、.NET Core、および.NET Standardがある。カンブリア紀の爆発から生まれた生物のように、.NETの爆発から出てきた多くの.NETの派生は、最終的に絶滅した。それらはもはやサポートされていないか、更新されていない。他の派生は、非常に狭く専門的な生態学的ニッチで生き続けている。特定の理由と目的のために開発された数種の ".NETの生き残り"が繁栄し、現在強くなってきている。この記事の目的は、さまざまな.NETの技術的詳細に深く関わることではない。この記事では、豊富な技術リソースを把握でき、その中のいくつかについては、その参照先を提供する。むしろ、この記事の目標は次の簡単な質問に答えることである。与えられた状況でどの.NETを使用するべきか？
.NET Framework
.NET Frameworkとして知られている.NETの実装は、オリジナルの.NETであり、他のすべての派生元である。これは、サポートされているAPI数とダウンロードサイズの両方で、.NETの最大のバージョンです。.NET Frameworkの多くのバージョンが長年にわたってリリースされ、それぞれに新しいAPIやその他の機能が追加されている。.NET Frameworkは、Microsoftが開発しサポートしており、Windowsマシン上でのみ動作する。
アプリケーションがWindows上でのみ実行される場合は、.NET Frameworkをターゲットにする必要がある。最大のAPIセットをサポートしているため、.NET Frameworkをターゲットとする場合、複雑なタスクを簡単に達成できるかどうかを心配する必要はほとんどない。しかし、最初からWindows以外のプラットフォームでアプリケーションを実行したい場合や、将来Windows以外のプラットフォームでアプリケーションを実行する可能性がある場合は、おそらく他の.NETの種類を検討する必要がある。
Mono
Monoは、.NET Frameworkとの互換性を目的としたオープンソースの.NET実装であり、Windows、macOS、Linuxなどのさまざまなプラットフォームで動作する。このプロジェクトは、Miguel de Icaza氏が率いる熱狂的な人たちによって立ち上げられた。Miguel de Icazaは、Windows以外のプラットフォームで.NETの利点を楽しめるべきだと考えており、これを達成する最善の方法はオープンソースの努力であった。de Icaza氏がXimianからNovell、Xamarin、Microsoftに移っていくに従って、Monoの管理は企業から企業へと移っていった。
Monoの.NETのAPIのカバレッジは完全ではないが、非常に良い。.NET FrameworkからMonoへの移植は非常に簡単で、カバーされていないAPIに対しては比較的簡単な回避策が存在する。
Monoはクロスプラットフォームの.NET実装のための有効な選択肢である。しかし、Microsoftはクロスプラットフォームの.NETの取り組みのほとんどを.NETコアに集中させているようであるため、将来を見据えれば考慮する必要があるだろう。また、Xamarin/Microsoftは、Monoへの取り組みをXamarinプラットフォームとiOSとAndroidのサポートに集中させているようだが、デスクトップやサーバープラットフォーム向けのMonoのサポートも活発になっているようある。要約すると、Windows用の.NET Frameworkアプリケーションを持っており、アプリケーションがWindows、macOS、Linux、BSD、および他のプラットフォームをサポートするようにしたいが、そのための.NETアプリケーションの変換に費やす労力を最小限にしたい場合、Monoはまだ最良の選択かもしれない。
.NET Core
.NET Coreは、オープンソースのクロスプラットフォーム.NET実装の1つで、こちらはMicrosoftの創業時から支えられてきた。また、Windows、macOS、Linuxもサポートしている。当初は、.NET Coreはやや軽量な実装であるように見えた。ASP.NETやコンソールアプリケーションをサポートするのには十分強力であり、それ以上はなかった。その後、Windows、macOS、Linuxで容易にサポートできる一部のAPIをサポートするように拡張されたようであったが、一方でWindows固有のレジストリなどのサポートは省略された。この時点では、APIのカバレッジがさらに広がっていくように見える。そのため、.NET Frameworkの再起動のように、複数のプラットフォームで利用できるように完全なものにしようとしている。一方で、Microsoftが今後サポートしたくないと考えているように思われるAPI（たとえば、.NETリモーティング）は避けている。Windows FormsやWPFなどのUI APIもサポートされていない（Microsoftは、.NET Coreの次期バージョンではWindows FormsやWPFなどのデスクトップアプリケーションプログラミングをサポートすることを発表したが、Windows上でアプリケーションを実行する場合のみ機能する）。
クロスプラットフォームの.NETには.NET Coreが将来有望であるため、Windows、macOS、Linuxで実行したい新しいアプリケーションを作成する場合は、 WebでないGUIを必要としない限り（WindowsフォームとWPFは使用できないため）.NET Coreをお勧めする。.NET Frameworkほど多くのAPIはないが、新しいアプリケーションを最初から始める場合は、この小さなAPIフットプリントを念頭に置いて設計することができる。ただし、既存の.NET Frameworkをクロスプラットフォームサポートに移行する場合は、必要とする重要なAPIをサポートしていない可能性があるため、.NETコアへの移行は非常に困難となる。Microsoftは、.NETコアにないWindows固有のAPIをサポートするWindows Compatibility Packなどの製品を提供していて、開発や移行が簡素化されるようにしている。しかし、それを使う場合、少なくとも.NET CoreがそれらのAPIを提供するまで、または自身でWindowsへの依存を取り除くためにコードを書き直すまで、Windowsにロックされる。
.NET Standard
.NET Standardは、複数のプラットフォーム間での.NETの使用をサポートするもう1つの取り組みである。.NET Framework、Mono、.NET Coreとは異なり、ランタイムとライブラリを備えた完全なパッケージではない。むしろ、.NET実装、特に.NET Framework、.NET Core、Xamarin（MicrosoftがサポートするMonoの派生で、iOS、Android、MacOS向け）でサポートされるべきAPIの仕様である。.NET Standard用に実装されたライブラリは、.NETプラットフォーム用にビルドされたすべてのアプリケーションで動作する必要がある。.NET Standardは、アプリケーションではなくライブラリのみをサポートしており、どこでも動作するライブラリを作成できるように設計されている。
最新のバージョンである.NET Standard 2.0は、非常に幅広いAPIをカバーしているが、欠けているAPIはまだ多数存在する。これは.NET Coreをかなりカバーしているが、かなりの量の.NET Frameworkは除外されている。もちろん、欠落しているAPIをターゲットにすることはできないが、代わりに.NET Standardではなく.NET Frameworkをターゲットにすることになる。欠落しているAPI呼び出しを取り除くまでは、.NET Frameworkに縛られることになる。
新しいライブラリセットを作成する場合は、.NET Standardをターゲットにすることをお勧めする。そうすれば、追加の作業なく、ライブラリを.NET Framework、.NET Core、Xamarin上で実行できる。もちろん、特定の.NETの派生をターゲットとしたアプリケーションを作成する必要がある。しかし、.NET StandardでサポートされていないGUIベースのクラスを含む、十分に小さいアプリケーションを作成し、共有ライブラリにほとんどの機能を入れることで、できるだけ多くのコードをクロスプラットフォームでサポートできるという利点がある。特定のAPIが欠けているため、既存の.NET Frameworkコードをもう一度移行する必要があるが、できるだけ多くのコードを.NET Standardライブラリに移行し、プラットフォーム固有のコードを分離した状態に保つことができる。クロスプラットフォームのシナリオで.NET Standardライブラリを使用する機会がある。そして、残りのコードを.NET Standardに移行するために時間を費やすこともできる。
ツールに関する簡単な説明
しばらくの間、各.NETの派生には専用の開発ツールが用意されていた。Visual Studioは.NET Framework用、MonoDevelopはMono用、Visual Studio Codeは（たいてい）.NET Core用であった。最近では、境界がぼやけている。Visual Studioを使用して.NET Frameworkに加えて、Xamarin、.NET Core、および.NET Standardの開発をすることができる。Visual Studio Codeはもともとはソースコードエディタでしたが、現在ははるかに完全な開発環境となり、.NET Frameworkまたは.NET Coreの開発をすることができる。Xamarin Studio（MonoDevelopベース）はWindows用ではなくなったが（Visual Studioを使用することが推奨されている）、Xamarinまたは.NET Coreの開発に使用できるMac用Visual Studioとして採用されている。したがって、徹底的に.NET Framework開発（Visual Studioを使用する必要がある）をしていない限り、他のニーズに基づいて実際に環境を選ぶことができる。
まとめ
.NETの爆発によって多くの.NETの派生が生まれた。その中にはいくつかは絶滅し、他は非常に狭いニッチで生きており、他は繁栄している。繁栄している.NETは、開発者が出会ったときによく混乱し、どちらを使用するのかがわからないほどよく似ている。しかし、そこからの選択はとても単純である。Windows上でのみ実行されるアプリケーションを作成する場合は、オリジナルの.NET Frameworkを使ってくだい。多くのプラットフォームでアプリケーションを実行し、完全な.NET Frameworkによって提供されるAPIに近いカバレッジが必要な場合は、Monoを使用してください。（Monoは、既存の.NET FrameworkアプリケーションをWindows以外の他のプラットフォームに移行する場合にも適している）。.NET Coreの制限されたAPIを使用して構築できるクロスプラットフォームアプリケーションを作成する場合は、.NET Coreをターゲットにしてください。最後に、.NET Framework、.NET Core、Xamarin上で実行可能なライブラリを作成し、特定のプラットフォーム向けのコンポーネントに、ユーザーインターフェイスなどのアプリケーションのプラットフォーム固有の部分を分離するために、.NET Standardを使用することを検討してください。
著者について
Wayne Citrin博士は、Javaと.NETフレームワークに接続する相互運用性ツールの有力プロバイダーであるJNBridge、LLCのCTOで共同創業者である。Citrinは、.NETとBizTalk向けにJNBridgeProとJMS Adapterのブリッジテクノロジで受賞したアーキテクトであり、.NETのベータ版以降、Javaと.NETの相互運用性の問題を解決しています。 Citrinはプログラミング言語とコンパイラの研究リーダーを務め、コロラド大学ボルダー校のコンピュータエンジニアリング教員を務めた。