.NET フレームワーク

.NET フレームワーク

.NET Framework コンポーネント スタック
開発者	マイクロソフト
初回リリース	2002年2月13日; 22年前 ( 2002-02-13 )
安定版リリース	4.8.1 / 2022年8月9日; 2年前[1] ( 2022-08-09 )
オペレーティング·システム	Windows 98以降、Windows NT 4.0以降
プラットフォーム	IA-32、x86-64、ARM
含まれるもの	マイクロソフトウィンドウズ
後継	。ネット
タイプ	ソフトウェアフレームワーク
ライセンス	混合。§ ライセンスを参照
Webサイト	マイクロソフト

.NET Framework (「ドット ネット」と発音) は、Microsoftが開発した独自のソフトウェア フレームワークで、主にMicrosoft Windowsで動作します。クロスプラットフォーム.NETプロジェクトに取って代わられるまでは、共通言語インフラストラクチャ(CLI)の主要な実装でした。フレームワーク クラス ライブラリ(FCL)と呼ばれる大規模なクラス ライブラリが含まれており、複数のプログラミング言語間で言語の相互運用性(各言語で他の言語で記述されたコードを使用できる)を提供します。.NET Framework 用に記述されたプログラムは、共通言語ランタイム(CLR) と呼ばれるソフトウェア環境 (ハードウェア環境とは対照的) で実行されます。CLR は、セキュリティ、メモリ管理、例外処理などのサービスを提供するアプリケーション仮想マシンです。そのため、.NET Framework を使用して記述されたコンピュータ コードは「マネージ コード」と呼ばれます。FCL と CLR が一緒になって .NET Framework を構成します。

FCL は、ユーザー インターフェイス、データ アクセス、データベース接続、暗号化、Web アプリケーション開発、数値アルゴリズム、およびネットワーク通信を提供します。プログラマーは、ソース コードと .NET Framework およびその他のライブラリを組み合わせてソフトウェアを作成します。このフレームワークは、Windows プラットフォーム用に作成されたほとんどの新しいアプリケーションで使用されることを目的としています。Microsoft は、 Visual Studioと呼ばれる .NET ソフトウェア用の統合開発環境も作成しています。

.NET Framework はプロプライエタリソフトウェアとして始まりましたが、同社は最初のリリースの前から、ソフトウェアスタックの標準化に取り組んでいました。標準化の取り組みにもかかわらず、開発者、主にフリーおよびオープンソースソフトウェアコミュニティの開発者は、特にソフトウェア特許に関して、選択された用語とフリーおよびオープンソースの実装の見通しに不安を表明しました。それ以来、マイクロソフトは、懸念に対処することを約束する特許の更新を発行するなど、.NET 開発をコミュニティ開発ソフトウェアプロジェクトの現代的なモデルにさらに厳密に従うように変更しました。^[2]

2019年4月、マイクロソフトは独自仕様のフレームワークの最後のメジャーバージョンとなる.NET Framework 4.8をリリースし、2022年8月には.NET Framework 4.8.1をリリースしました。それ以降、このバージョンには毎月のセキュリティと信頼性のバグ修正のみがリリースされています。このバージョンに対するさらなる変更は予定されていません。.NET Frameworkは、Windowsの今後のリリースにも引き続き含まれ、セキュリティ更新プログラムを受け取り続けます。2024年9月時点で削除される予定はありません。^[3]

Microsoft は、 .NET 戦略の一環として、当初は Next Generation Windows Services (NGWS) という名前で、1990 年代後半に .NET Framework の開発を開始しました。2000 年初頭までに、.NET 1.0 の最初のベータ バージョンがリリースされました。

2000年8月、マイクロソフトとインテルは共通言語基盤（CLI）とC#の標準化に取り組みました。2001年12月までに、両方ともECMA標準に承認されました。^{[4] [5]} 国際標準化機構（ISO）は2003年4月に続きました。ISO標準の現在のバージョンは、ISO/IEC 23271:2012とISO/IEC 23270:2006です。^{[6] [7]}

マイクロソフトとそのパートナーは CLI と C# の特許を保有しているが、ECMA と ISO は実装に不可欠なすべての特許を「合理的かつ非差別的な条件」で利用できるようにすることを要求している。両社はこれらの条件を満たし、特許をロイヤリティフリーで利用できるようにすることに合意した。ただし、これは ECMA-ISO 標準でカバーされていない .NET Framework の部分 ( Windows Forms、ADO.NET、ASP.NETなど) には適用されなかった。マイクロソフトがこれらの分野で保有する特許は、マイクロソフト以外の企業によるフレームワーク全体の実装を阻むものだった可能性がある。^[8]

Windows Vista は、 .NET Framework を統合した最初の Windows クライアント バージョンです。

2007 年 10 月 3 日、マイクロソフトは.NET Framework 3.5 ライブラリのソース コードをMicrosoft Reference Source License (Ms-RSL ^[a] )の下で公開すると発表しました。^[9]ソース コード リポジトリは 2008 年 1 月 16 日にオンラインで公開され、BCL、ASP.NET、ADO.NET、Windows Forms、WPF、XML が含まれていました。マイクロソフトのScott Guthrieは、 LINQ、WCF、WF ライブラリが追加されると約束しました。^[10]

.NET Framework のバリアントである .NET Compact Frameworkおよび.NET Micro Framework は、Windows Mobile、Windows CE、その他のリソースが制限された組み込みデバイスなどの他の Microsoft プラットフォームのサポートを提供しました。Silverlightは、プラグインを介して Web ブラウザーのサポートを提供しました。

2014 年 11 月、マイクロソフトは特許付与の更新も発表し、これにより、以前の誓約の範囲がさらに拡大されました。マイクロソフトの以前の付与は、厳密には ECMA-334 と ECMA-335 のそれぞれ第 4 版を含む「対象仕様」のテクノロジにのみ適用されていたため、Mono などの以前のプロジェクトは法的にグレーゾーンにありました。ただし、新しい特許の約束では、仕様バージョンに上限はなく、プロジェクトが実装することを選択した場合、ECMA グループによって正式に指定されていない MSDN に文書化された .NET ランタイム テクノロジにも適用されます。これにより、Mono やその他のプロジェクトは、第 4 版の公開以降に導入された最新の .NET 機能と機能の同等性を維持でき、それらの機能の実装に関する特許訴訟のリスクを負うことはありません。新しい付与では、実装は CLI 仕様の必須部分への最低限の準拠を維持する必要があるという制限が維持されています。^[11]

2016年3月31日、マイクロソフトはMicrosoft Buildで、以前は商用ライセンスが必要だったシナリオでも、MITライセンスの下でMonoを完全に再ライセンスすると発表した。 ^[12]また、マイクロソフトはMonoに関する以前の特許の約束を補足し、「Monoを使用、販売、販売の申し出、輸入、または配布している」当事者に対して「適用可能な特許」を主張しないと述べた。^{[13] [14]} Monoプロジェクトが.NET Foundationに寄贈されたことが発表された。これらの展開は、2016年2月に始まり、2016年3月18日に完了したXamarinの買収に続くものである。^[15]

マイクロソフトのプレスリリースでは、クロスプラットフォームへの取り組みにより、完全にオープンソースで最新のサーバーサイド.NETスタックが可能になったことが強調されています。マイクロソフトは、2018年12月4日にWPF、Windows Forms、 WinUIのソースコードをリリースしました。 ^[16]

共通言語インフラストラクチャ (CLI) は、アプリケーションの開発と実行のための言語に依存しないプラットフォームを提供します。CLI の範囲内で .NET Framework のコア部分を実装することにより、これらの機能は 1 つの言語に縛られることなく、フレームワークでサポートされている多くの言語で利用できるようになります。

.NET Framework には、共通言語ランタイム (CLR) が含まれています。これは、.NET Framework の実行エンジンとして機能し、メモリ管理、タイプ セーフティ、例外処理、ガベージ コレクション、セキュリティ、スレッド管理などの多くのサービスを提供します。.NET Framework 用に作成されたすべてのプログラムは、CLR によって実行されます。

.NET Framework 用に作成されたプログラムは、マシン コードに直接コンパイルされるのではなく、共通中間言語 (CIL) コードにコンパイルされます。実行中、アーキテクチャ固有のジャストインタイム コンパイラ(JIT) がCIL コードをマシン コードに変換します。

コンパイルされた CIL コードは、CLI アセンブリに格納されます。仕様で義務付けられているように、アセンブリは、Windows プラットフォームのすべてのダイナミック リンク ライブラリ(DLL) および実行可能EXEファイルに共通するポータブル実行可能 (PE) ファイル形式で格納されます。各アセンブリは 1 つ以上のファイルで構成され、そのうちの 1 つにはアセンブリのメタデータを含むマニフェストが含まれている必要があります。アセンブリの完全な名前 (ディスク上のファイル名と混同しないでください) には、単純なテキスト名、バージョン番号、カルチャ、および公開キートークンが含まれます。アセンブリが同じ完全な名前を共有している場合、それらのアセンブリは同等であると見なされます。

アセンブリの作成者は、厳密な名前付けのために秘密キーを使用することもできます。公開キー トークンによって、アセンブリの署名者の実際の ID が決定されます。以前のバージョンのアセンブリと同じ厳密な名前を持つアセンブリに署名できるのは、(二重キー暗号化システムの) 秘密キーを知っている人だけです。アセンブリをグローバル アセンブリ キャッシュに追加するには、厳密な名前付けが必要です。

Visual Studio 2015以降、.NETネイティブコンパイルテクノロジにより、ユニバーサルWindowsプラットフォームアプリの.NETコードをCILコードではなくマシンコードに直接コンパイルできるようになりましたが、アプリはC#またはVisual Basic.NETで記述されている必要があります。^[17]

.NET Framework には、CLI 基本標準ライブラリの実装が含まれています。.NET Framework クラス ライブラリ (FCL) は、名前空間の階層に編成されています。組み込みのアプリケーション プログラミング インターフェイスSystem.*(API) のほとんどは、または名前空間の一部ですMicrosoft.*。これらのクラス ライブラリは、ファイルの読み取りと書き込み、グラフィック レンダリング、データベース操作、XML ドキュメント操作など、多くの一般的な機能を実装します。クラス ライブラリは、すべてのCLI 準拠言語で使用できます。FCL は、CLI基本クラス ライブラリ(BCL) とその他のクラス ライブラリを実装します。これらのクラス ライブラリには、CLI によって指定されるものもあれば、Microsoft 固有のものもあります。

BCLにはクラスライブラリ全体の小さなサブセットが含まれており、 CLRの基本APIとして機能するクラスのコアセットです。 ^[18] .NET Frameworkの場合、BCLの一部であると見なされるほとんどのクラスはmscorlib.dll、、System.dllおよびに存在します。BCLクラスは、.NET Frameworkだけでなく、.NET Compact Framework、Microsoft Silverlight、.NET Core、MonoSystem.Core.dllなどのCLIの代替実装でも使用できます。

FCL は、.NET Framework に同梱されているクラス ライブラリ全体を指します。これには、Windows Forms、ASP.NET、Windows Presentation Foundation (WPF) などの拡張ライブラリ セットである BCL のほか、基本クラス ライブラリADO.NET、Language Integrated Query (LINQ)、Windows Communication Foundation (WCF)、Workflow Foundation (WF) の拡張機能が含まれます。FCL は、 C++などの言語の標準ライブラリよりも範囲がはるかに広く、Java の標準ライブラリと同等の範囲です。

代替の CLI 実装 (Silverlight など) の導入に伴い、Microsoft はポータブル クラス ライブラリ (PCL) の概念を導入し、使用ライブラリを複数の実装で実行できるようにしました。実装がさらに普及するにつれて、PCL アプローチは拡張できなくなりました (PCL は、2 つ以上の実装間の API サーフェスの交差を定義します)。^[19] PCL の次の進化ステップとして、UWP と Silverlight にあるベース API に基づいて遡及的に .NET 標準ライブラリが作成されましたSystem.Runtime.dll。新しい CLI 実装では、標準ライブラリのバージョンを実装することが推奨されており、既存のサードパーティ ライブラリを実行できるため、新しいバージョンを作成する必要はありません。.NET 標準ライブラリにより、.NET アーキテクチャ内でライブラリとアプリ モデル レイヤーを独立して進化させることができます。^[20]

NuGet は、すべての .NET プラットフォーム用のパッケージ マネージャーです。NuGet.org のグローバル ライブラリ フィードを使用して、サードパーティのライブラリを .NET プロジェクトに取り込むために使用されます。^[21]プライベート フィードは、ビルド サーバーやファイル システム ディレクトリなどによって個別に管理できます。

Microsoft はVisual Studio 2005でC++/CLI を導入しました。これは、 Visual C++プログラムをコンパイルして .NET Framework 内で実行するための言語および手段です。C++ プログラムの一部は、依然としてアンマネージVisual C++ランタイム内で実行されますが、特別に変更された部分はCIL コードに変換され、.NET Framework のCLRで実行されます。

C++/CLIコンパイラを使用してコンパイルされたアセンブリは、同じDLLにネイティブコードとマネージコードが含まれているため、混合モードアセンブリと呼ばれます。^{[22]このようなアセンブリは、} .NET Reflectorなどの.NETデコンパイラがマネージコードのみを明らかにする ため、リバースエンジニアリングがより複雑になります。

コンピュータ システムでは、一般的に新しいアプリケーションと古いアプリケーション間のやり取りが必要になるため、.NET Framework は、.NET 環境外で実行される新しいプログラムと古いプログラムに実装されている関数にアクセスする手段を提供します。コンポーネント オブジェクト モデル(COM) コンポーネントへのアクセスは、フレームワークの名前空間で提供されますSystem.Runtime.InteropServices。System.EnterpriseServices他の関数へのアクセスは、プラットフォーム呼び出しサービス(P/Invoke) を介して行われます。ネイティブ アプリケーションから .NET 関数へのアクセスは、逆の P/Invoke 関数を介して行われます。

.NET Frameworkでは、CLR でサポートされるすべてのデータ型とプログラミング構造、およびそれらが CLI 仕様に準拠してどのように相互作用するかを定義する共通型システム(CTS) が導入されています。この機能により、.NET Framework は、準拠する任意の CLI 言語を使用して記述されたライブラリとアプリケーション間での型とオブジェクト インスタンスの交換をサポートします。

.NET Framework で使用される CTS と CLR も、型の安全性を強化します。これにより、定義の不適切なキャスト、間違ったメソッドの呼び出し、およびオブジェクトにアクセスするときのメモリ サイズの問題が防止されます。また、これにより、ほとんどの CLI 言語が静的に型付けされます (型推論の有無にかかわらず)。ただし、.NET Framework 4.0 以降では、動的言語ランタイムによってCLR が拡張され、動的に型付けされた言語を CLI 上に実装できるようになりました。

マイクロソフトは、Microsoft Windows以外のシステムに完全なフレームワークを実装したことはありませんが、フレームワークをクロスプラットフォームに設計しており、^[23]他のオペレーティングシステム向けの実装も利用可能です（Silverlightおよび§ 代替実装を参照）。マイクロソフトは、CLI（基本クラスライブラリ、CTS、CILを含む）、^{[24] [25] [26]} C#、^[5]およびC++/CLI ^{[27]の仕様を}Ecma International（ECMA）と国際標準化機構（ISO）の両方に提出し、公式標準として利用できるようにしました。これにより、サードパーティがフレームワークとその言語の互換性のある実装を他のプラットフォームで作成できるようになりました。

Coreクロスプラットフォーム.NET（旧.NET Core）は、多くのLinuxディストリビューションやMacOSでも正式に利用可能となっている。^[28]

.NET Framework には、コード アクセス セキュリティ(CAS) と検証および確認という 2 つの一般的な機能を備えた独自のセキュリティ メカニズムがあります。CAS は、特定のアセンブリに関連付けられた証拠に基づいています。通常、証拠はアセンブリのソースです (ローカル マシンにインストールされているか、インターネットからダウンロードされているか)。CAS は証拠を使用して、コードに付与されるアクセス許可を決定します。呼び出し元のコードが特定のアクセス許可の付与を要求すると、CLR は呼び出しスタック ウォークを実行し、呼び出しスタック内の各メソッドのすべてのアセンブリで必要なアクセス許可を確認します。アクセス許可が付与されていないアセンブリがある場合は、セキュリティ例外がスローされます。

マネージ CILバイトコードは、難読化されていない限り、ネイティブ コードよりもリバース エンジニアリングが容易です。^[29] .NETデコンパイラプログラムを使用すると、リバース エンジニアリングのスキルを持たない開発者でも、難読化されていない .NET アセンブリのソース コードを表示できます。対照的に、ネイティブ マシン コードにコンパイルされたアプリはリバース エンジニアリングがはるかに難しく、主にコンパイラの最適化とリフレクションの欠如のために、ソース コードが正常に生成されることはほとんどありません。^{[30]このため、ビジネス コミュニティでは、}企業秘密の漏洩やライセンス管理メカニズムのバイパスの可能性について懸念が生じています。これを軽減するために、Microsoft は2002 年からVisual Studio .NETにDotfuscator Community Editionを同梱しています。^[b] VMware、Vi Labs、Turbo、Red Gate Softwareなどのベンダーから、サード パーティの難読化ツールも入手できます。.NET コード用のメソッド レベルの暗号化ツールは、 SafeNetなどのベンダーから入手できます。

CLR は、メモリ管理 (割り当てと完了時の解放) の負担から開発者を解放します。メモリを安全に解放できるタイミングを検出することで、メモリ管理を CLR 自体が処理します。.NET 型 (オブジェクト) のインスタンス化は、マネージド ヒープ (CLR によって管理されるメモリ プール) から割り当てられます。オブジェクトへの参照 (直接参照またはオブジェクトグラフ経由) が存在する限り、オブジェクトは使用中であると見なされます。オブジェクトへの参照が存在せず、オブジェクトにアクセスまたは使用できない場合、そのオブジェクトはガベージとなり、コレクションの対象になります。

.NET Framework には、アプリケーションのスレッドとは別のスレッドで定期的に実行されるガベージ コレクター(GC)が含まれており、使用できないオブジェクトをすべて列挙し、それらに割り当てられたメモリを再利用します。これは、非決定性で圧縮型のマーク アンド スイープガベージ コレクターです。GC は、設定された量のメモリが使用されたとき、またはシステムでメモリに十分な負荷がかかっているときにのみ実行されます。メモリを再利用するための条件がいつ達成されるかは保証されていないため、GC の実行は非決定性です。各 .NET アプリケーションには、マネージ ヒープ上のオブジェクト (マネージ オブジェクト)へのポインターであるルートのセットがあります。これらには、静的オブジェクトへの参照、現在スコープ内にあるローカル変数またはメソッド パラメーターとして定義されたオブジェクト、CPU レジスタによって参照されるオブジェクトが含まれます。^[31] GC が実行されると、アプリケーションが一時停止し、ルートで参照されているオブジェクトごとに、ルート オブジェクトから到達可能なすべてのオブジェクトを再帰的に列挙し、到達可能としてマークします。 CLI メタデータとリフレクションを使用して、オブジェクトによってカプセル化されたオブジェクトを検出し、それらを再帰的にウォークします。次に、リフレクションを使用してヒープ上のすべてのオブジェクト (最初は連続して割り当てられていた) を列挙します。到達可能としてマークされていないすべてのオブジェクトはガベージです。 ^{[31]これは}マークフェーズです。 ^[32]ガベージによって保持されるメモリは重要ではないため、空き領域と見なされます。ただし、これにより、最初は連続していたオブジェクト間に空き領域のチャンクが残ります。次に、オブジェクトはまとめて圧縮され、管理対象ヒープ上の空き領域が再び連続します。^{[31] [32]}オブジェクトの移動によって無効になったオブジェクトへの参照は、GC によって新しい場所を反映するように更新されます。^[32]ガベージ コレクションが終了すると、アプリケーションが再開されます。最新バージョンの .NET Framework では、ユーザー コードとともに並行ガベージ コレクションが使用され、バックグラウンドで実行されるため、一時停止が目立ちません。^[33]

.NET Framework が使用するガベージ コレクターも世代別です。^{[34]オブジェクトには}世代が割り当てられます。新しく作成されたオブジェクトには世代 0 のタグが付けられます。1 回のガベージ コレクションを生き残ったオブジェクトには世代 1のタグが付けられます。別のコレクションを生き残った世代 1 のオブジェクトは世代 2です。フレームワークは最大で世代 2 のオブジェクトを使用します。^[34]世代の高いオブジェクトは、世代の低いオブジェクトよりもガベージ コレクションされる頻度が低くなります。古いオブジェクトは新しいオブジェクトよりも寿命が長い傾向があるため、これによりガベージ コレクションの効率が向上します。^[34]ほとんどのコレクション実行で古いオブジェクトを無視することで、合計で必要なチェックと圧縮操作が少なくなります。^[34]

アプリケーションが最初に起動されると、.NET Framework はジャストインタイムコンパイラを使用してCIL コードを実行可能コードにコンパイルし、実行可能プログラムを .NET ネイティブイメージキャッシュにキャッシュします。^{[35] [36]}キャッシュにより、アプリケーションの初回起動は通常遅くなりますが、それ以降の起動は速くなります。初回起動を高速化するために、開発者はネイティブイメージジェネレータユーティリティを使用して、任意の .NET アプリケーションを手動で事前にコンパイルしてキャッシュすることができます。^[36]

環境に統合されているガベージコレクターは、開発者が直接制御できない予期しない実行遅延を引き起こす可能性があります。「大規模なアプリケーションでは、ガベージコレクターが処理する必要があるオブジェクトの数が非常に大きくなる可能性があります。つまり、すべてのオブジェクトにアクセスして再配置するには非常に長い時間がかかる可能性があります。」^[37]

.NET Framework は、2014 年 4 月の Visual Studio 2013 Update 2 から、マネージ コード経由でストリーミング SIMD 拡張命令( SSE)を呼び出すためのサポートを提供しています。ただし、 Mono は2009 年に Mono.Simd 名前空間内でバージョン 2.2 の時点で SIMD 拡張命令のサポートを提供しています。 ^[38] Mono の主任開発者Miguel de Icaza は、この SIMD サポートが CLR の ECMA 標準に採用されることを期待していると表明しています。^{[39]ストリーミング SIMD 拡張命令は、} Pentium IIIの導入以来、x86 CPUで利用できるようになりました。ARMやMIPSなどの他のアーキテクチャにも SIMD 拡張命令があります。CPU がこれらの拡張命令をサポートしていない場合、命令はソフトウェアでシミュレートされます。^{[40] [41]}

.NETがリリースされるまで、.NET Framework は CLI の主な実装でした。フレームワークの一部には他の実装も存在します。ランタイム エンジンは ECMA-ISO 仕様で説明されていますが、他の実装は特許の問題に悩まされる可能性があります。ISO 標準には、「このドキュメントの一部の要素が特許権の対象となる可能性があることに留意してください。ISO は、そのような特許権の一部またはすべてを特定することについて責任を負いません。」という免責事項が含まれる場合があります。^[42] FCL はオープン スタンダードで説明されておらず、著作権制限の対象となる可能性があるため、代替品を開発するのは困難です。また、FCL の一部には Windows 固有の機能と動作があるため、Windows 以外のプラットフォームでの実装には問題が生じる可能性があります。

フレームワークの一部の代替実装をいくつかここに示します。

• .NET Micro Frameworkは、リソースが極端に限られたデバイス向けの .NET プラットフォームです。CLR の小型バージョンが含まれており、C#での開発 (一部の開発者は、ある程度のハッキングと機能制限はあるものの、 VB.NET を使用できました^[43] ) とデバッグ (エミュレータ内またはハードウェア上) をサポートしており、どちらもMicrosoft Visual Studio を使用しています。また、.NET Framework クラス ライブラリのサブセット (約 70 のクラスと約 420 のメソッド)、 WPF に基づいたGUIフレームワーク、組み込みアプリケーション固有の追加ライブラリも備えています。
• Mono はCLI と FCL の実装であり、追加機能を提供します。これはMIT ライセンスの下で無料ソフトウェアとしてライセンスされます。幅広いアーキテクチャとオペレーティング システム向けの ASP.NET、ADO.NET、および Windows フォーム ライブラリのサポートが含まれています。また、C# および VB.NET コンパイラも含まれています。
• Portable.NET ( DotGNUの一部) は、CLI の実装、FCL の一部、および C# コンパイラを提供します。さまざまな CPU とオペレーティング システムをサポートしています。このプロジェクトは中止され、最後の安定リリースは 2009 年でした。
• Microsoft Shared Source Common Language Infrastructure は、 CLR の非フリー実装です。ただし、最新バージョンは Windows XP SP2 でのみ実行され、2006 年以降更新されていません。そのため、.NET Framework バージョン 2.0 のすべての機能は含まれていません。
• CrossNet ^{[44]はCLIとFCLの一部を実装したもので、オープンソースの}MITライセンスを使用したフリーソフトウェアです。

Microsoft マネージド コード フレームワークとそのコンポーネントは、次のようにライセンスされます。

• Microsoft Foundation Class ライブラリ(MFC)。.NET Framework 以前の Windows ベースのアプリケーション プログラミングを容易にするために使用されたオブジェクト指向の抽象化です。
• .NET (旧 .NET Core)
• CLI言語のリスト
• 標準ライブラリ (CLI)、.NET 標準ライブラリ
• 基本クラスライブラリ(BCL)

Wikibooks には、 .NET 開発基盤に関する書籍があります。

Wikiversity には.NET 入門に関する学習リソースがあります

• 公式サイト
• .NET Framework の概要 (MSDN)
• .NET Github リポジトリ