Loading article…
.NET Framework （ドットネットと発音）は、Microsoftが開発した独自のソフトウェアフレームワークで、主にMicrosoft Windows上で動作します。クロスプラットフォームの.NETプロジェクトに取って代わられるまでは、共通言語インフラストラクチャ（CLI）の主要な実装でした。Framework Class Library（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 リリースにも引き続き含まれ、セキュリティ アップデートが引き続き提供され、2025 年 7 月現在、削除する予定はありません。[ 3 ]
マイクロソフトは、1990年代後半に.NET Frameworkの開発を開始しました。当初は、マイクロソフトの.NET戦略の一環として、次世代Windowsサービス（NGWS）という名称で開発が進められていました。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 ]
Microsoft とそのパートナーは CLI と C# の特許を保有していますが、ECMA と ISO は、実装に不可欠なすべての特許を「合理的かつ差別的でない条件」で利用可能にすることを要求しています。両社はこの条件を満たし、特許を無償で利用可能にすることに同意しました。しかし、これは ECMA-ISO 標準でカバーされていない .NET Framework の部分、つまりWindows Forms、ADO.NET、およびASP.NETには適用されませんでした。これらの分野で Microsoft が保有する特許は、完全なフレームワークの Microsoft 以外の実装を阻害した可能性があります。[ 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 月、マイクロソフトは特許付与の更新も行い、以前の約束を超えて範囲をさらに拡大しました。以前のMonoなどのプロジェクトは、マイクロソフトの以前の特許付与が「対象仕様」の技術にのみ適用され、ECMA-334 と ECMA-335 の第 4 版のみに限定されていたため、法的にグレー な領域にありました。しかし、新しい特許の約束では、仕様のバージョンに制限はなく、プロジェクトが実装することを選択した場合、ECMA グループによって正式に仕様化されていない MSDN に記載されている .NET ランタイム技術にも適用されます。これにより、Mono や他のプロジェクトは、第 4 版の公開以降に導入された最新の .NET 機能と機能の同等性を維持しながら、それらの機能の実装に関する特許訴訟のリスクを負うことなく済みます。[ 11 ]新しい特許付与では、実装は CLI 仕様の必須部分への最低限の準拠を維持しなければならないという制限は維持されています。[ 12 ]
2016 年 3 月 31 日、マイクロソフトはMicrosoft Buildで、以前は商用ライセンスが必要だったシナリオでもMono をMIT ライセンスで完全に再ライセンスすると発表した。 [ 13 ]マイクロソフトはまた、Mono の以前の特許に関する約束を補足し、「Mono を使用、販売、販売の申し出、輸入、または配布する」当事者に対して「適用可能な特許」を主張しないと表明した。[ 14 ] [ 15 ] Mono プロジェクトが .NET Foundation に貢献したことが発表された。これらの展開は、2016 年 2 月に開始され、2016 年 3 月 18 日に完了したXamarinの買収に続くものだった。 [ 16 ]
マイクロソフトのプレスリリースでは、クロスプラットフォームへの取り組みにより、完全にオープンソースの最新のサーバーサイド.NETスタックが可能になったことが強調されています。[ 2 ]マイクロソフトは、 2018年12月4日にWPF、Windows Forms、WinUIのソースコードを公開しました。 [ 17 ]
共通言語インフラストラクチャ（CLI）は、アプリケーションの開発と実行のための言語に依存しないプラットフォームを提供します。.NET Frameworkの中核となる機能をCLIの範囲内で実装することで、これらの機能は特定の言語に限定されることなく、フレームワークがサポートする多くの言語で利用できるようになります。
.NET Frameworkには共通言語ランタイム（CLR）が含まれています。CLRは.NET Frameworkの実行エンジンとして機能し、メモリ管理、型安全性、例外処理、ガベージコレクション、セキュリティ、スレッド管理など、多くのサービスを提供します。.NET Framework向けに作成されたすべてのプログラムはCLRによって実行されます。
.NET Framework 用に作成されたプログラムは、直接マシンコードにコンパイルされるのではなく、共通中間言語 (CIL) コードにコンパイルされます。実行時には、アーキテクチャ固有のジャストインタイムコンパイラ(JIT) がCIL コードをマシンコードに変換します。
コンパイルされた CLI コードはCLI アセンブリに格納されます。仕様で規定されているとおり、アセンブリはポータブル実行可能ファイル (PE) ファイル形式で格納されます。これは、Windows プラットフォームで全てのダイナミック リンク ライブラリ(DLL) および実行可能ファイル(EXE ) に共通する形式です。各アセンブリは 1 つ以上のファイルで構成され、そのうちの 1 つにはアセンブリのメタデータを含むマニフェストが含まれている必要があります。アセンブリの完全な名前 (ディスク上のファイル名と混同しないように注意) には、その単純なテキスト名、バージョン番号、カルチャ、および公開鍵トークンが含まれます。アセンブリは、完全な名前が同じであれば同等とみなされます。
アセンブリの作成者は、秘密鍵を使用して強力な名前付けを行うこともできます。公開鍵トークンは、アセンブリの署名者の実世界における身元を決定します。二重鍵暗号方式の秘密鍵を知っている者のみが、以前のバージョンのアセンブリと同じ強力な名前を持つアセンブリに署名できます。アセンブリをグローバルアセンブリキャッシュに追加するには、強力な名前付けが必要です。
Visual Studio 2015以降、.NET Nativeコンパイル技術により、Universal Windows Platformアプリの.NETコードをCILコードではなくマシンコードに直接コンパイルできるようになりましたが、アプリはC#またはVisual Basic.NETで記述されている必要があります。[ 18 ]
.NET Framework には、CLI の基盤となる標準ライブラリの実装が含まれています。.NET Framework クラス ライブラリ (FCL) は、名前空間の階層構造になっています。組み込みのアプリケーション プログラミング インターフェイス(API)のほとんどはSystem.*、またはMicrosoft.*名前空間の一部です。これらのクラス ライブラリは、ファイルの読み書き、グラフィック レンダリング、データベースとのやり取り、XML ドキュメントの操作など、多くの共通機能を実装しています。クラス ライブラリは、CLI に準拠するすべての言語で使用できます。FCL は、CLIベース クラス ライブラリ(BCL) およびその他のクラス ライブラリを実装しています。これらのライブラリの中には、CLI で指定されているものと、Microsoft 固有のものがあります。
BCL はクラスライブラリ全体のごく一部であり、CLR の基本APIとして機能するクラスのコアセットです。[ 19 ] .NET Framework では、BCL の一部と見なされるクラスのほとんどはmscorlib.dll、、System.dllおよびにありますSystem.Core.dll。BCL クラスは、.NET Framework だけでなく、.NET Compact Framework、Microsoft Silverlight、.NET Core、Monoなどの CLI の代替実装でも使用できます。
FCLとは、.NET Frameworkに付属するクラスライブラリ全体を指します。これには、BCL、Windows Forms、ASP.NET、Windows Presentation Foundation (WPF)などの拡張ライブラリ、および基本クラスライブラリであるADO.NET、Language Integrated Query (LINQ)、Windows Communication Foundation (WCF)、Workflow Foundation (WF)の拡張機能が含まれます。FCLは、 C++などの言語の標準ライブラリよりもはるかに規模が大きく、 Javaの標準ライブラリと同程度の規模です。
代替の CLI 実装 (Silverlight など) の導入に伴い、Microsoft はポータブル クラス ライブラリ (PCL) の概念を導入し、コンシューマー ライブラリを複数の実装で実行できるようにしました。実装がさらに増加すると、PCL アプローチはスケーラビリティに欠けるようになりました (PCL は、2 つ以上の実装間の API サーフェスの交差として定義されます)。[ 20 ] PCL の次の進化段階として、UWP および Silverlight で見つかったベース API に基づいて、.NET Standard Library が遡及的に作成されましたSystem.Runtime.dll。新しい CLI 実装は、Standard Library のバージョンを実装することが推奨されており、これにより、新しいバージョンを作成する必要なく、既存のサードパーティ ライブラリを実行できます。.NET Standard Library は、.NET アーキテクチャ内でライブラリ レイヤーとアプリ モデル レイヤーの独立した進化を可能にします。[ 21 ]
NuGet は、すべての .NET プラットフォーム用のパッケージ マネージャーです。NuGet.org のグローバル ライブラリ フィードを使用して、サードパーティ ライブラリを .NET プロジェクトに取得するために使用されます。[ 22 ]プライベート フィードは、ビルド サーバーやファイルシステム ディレクトリなどによって個別に管理できます。
MicrosoftはVisual Studio 2005でC++/CLIを導入しました。これは、 Visual C++プログラムを.NET Framework内で実行するためにコンパイルする言語および手段です。C++プログラムの一部は引き続きアンマネージドのVisual C++ランタイム内で実行されますが、特別に修正された部分はCILコードに変換され、.NET FrameworkのCLRで実行されます。
C++/CLI コンパイラを使用してコンパイルされたアセンブリは、同じ DLL 内にネイティブ コードとマネージド コードが含まれているため、混合モード アセンブリと呼ばれます。[ 23 ] .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 言語を使用して記述されたライブラリとアプリケーション間で、型とオブジェクト インスタンスの交換をサポートします。
CTSと.NET Frameworkで使用されるCLRは、型安全性も強制します。これにより、オブジェクトへのアクセス時に、定義されていないキャスト、誤ったメソッド呼び出し、メモリサイズの問題などが防止されます。また、これにより、ほとんどのCLI言語は静的型付け（型推論の有無にかかわらず）になります。しかし、.NET Framework 4.0以降、動的言語ランタイムがCLRを拡張し、動的型付け言語をCLI上に実装できるようになりました。
Microsoft は、Microsoft Windows 以外のシステムでフレームワーク全体を実装したことはありませんが、フレームワークをクロス プラットフォームに設計しており[ 24 ]、他のオペレーティングシステム向けの実装も利用可能です ( Silverlightおよび§ 代替実装を参照)。Microsoft は、CLI (基本クラス ライブラリ、CTS、CIL を含む) [ 25 ] [ 26 ] [ 27 ]、C# [ 5 ]、および C++/CLI [ 28 ]の仕様をEcma International (ECMA) と国際標準化機構(ISO)の両方に提出し、公式標準として公開しました。これにより、サードパーティが他のプラットフォームでフレームワークとその言語の互換性のある実装を作成できるようになります。
Core クロスプラットフォーム .NET (旧称 .NET Core) は、多くの Linux ディストリビューションおよび macOS でも正式に利用可能です。[ 29 ]
.NET Framework には、コード アクセス セキュリティ(CAS) と検証および確認という2 つの一般的な機能を備えた独自のセキュリティ メカニズムがあります。CAS は、特定のアセンブリに関連付けられた証拠に基づいています。通常、証拠はアセンブリのソース (ローカル マシンにインストールされているか、インターネットからダウンロードされたか) です。CAS は証拠を使用して、コードに付与されるアクセス許可を決定します。呼び出し元のコードが特定のアクセス許可を要求すると、CLR は呼び出しスタックを走査して、呼び出しスタック内の各メソッドのすべてのアセンブリに必要なアクセス許可があるかどうかを確認します。いずれかのアセンブリにアクセス許可が付与されていない場合、セキュリティ例外がスローされます。
マネージドCILバイトコードは、難読化されていない限り、ネイティブ コードよりもリバース エンジニアリングが容易です。[ 30 ] .NETデコンパイラプログラムを使用すると、リバース エンジニアリング スキルを持たない開発者でも、難読化されていない .NET アセンブリのソース コードを表示できます。対照的に、ネイティブ マシン コードからコンパイルされたアプリはリバース エンジニアリングがはるかに難しく、コンパイラの最適化とリフレクションの欠如が主な理由で、ソース コードが正常に生成されることはほとんどありません。[ 31 ]このため、企業秘密の漏洩やライセンス制御メカニズムの回避の可能性について、ビジネス コミュニティで懸念が生じています。これを軽減するために、Microsoft は2002 年以降、Visual Studio .NETにDotfuscator Community Editionを含めています。 [ b ] VMware、Vi Labs、Turbo、Red Gate Softwareなどのベンダーからもサードパーティの難読化ツールが提供されています。SafeNetなどのベンダーからは、.NET コードのメソッド レベル暗号化ツールが提供されています。
CLRは、開発者がメモリ管理（割り当てと解放）の負担から解放されるようにします。メモリを安全に解放できるタイミングを検出することで、メモリ管理をCLR自体が行います。.NET型（オブジェクト）のインスタンスは、CLRが管理するメモリプールであるマネージドヒープから割り当てられます。オブジェクトへの参照が存在する限り（直接参照でも、オブジェクトグラフを介した参照でも構いません）、そのオブジェクトは使用中とみなされます。オブジェクトへの参照が存在せず、アクセスも使用もできない場合、そのオブジェクトはガベージとなり、ガベージコレクションの対象となります。
.NET Framework には、アプリケーションのスレッドとは別のスレッドで定期的に実行されるガベージ コレクタ(GC) が含まれており、使用できないオブジェクトをすべて列挙し、それらに割り当てられたメモリを解放します。これは、非決定論的で、圧縮型のマーク アンド スイープガベージ コレクタです。GC は、一定量のメモリが使用されたとき、またはシステムでメモリに対する十分な負荷がかかったときにのみ実行されます。メモリを解放する条件がいつ満たされるかは保証されていないため、GC の実行は非決定論的です。各 .NET アプリケーションには、マネージド ヒープ上のオブジェクト (マネージド オブジェクト) へのポインタであるルートのセットがあります。これには、静的オブジェクトへの参照、現在スコープ内にあるローカル変数またはメソッド パラメーターとして定義されたオブジェクト、および CPU レジスタによって参照されるオブジェクトが含まれます。[ 32 ] GC が実行されると、アプリケーションが一時停止され、ルートで参照される各オブジェクトについて、ルート オブジェクトから到達可能なすべてのオブジェクトを再帰的に列挙し、到達可能としてマークします。 CLI メタデータとリフレクションを使用して、オブジェクトによってカプセル化されたオブジェクトを検出し、それらを再帰的に走査します。次に、リフレクションを使用して、ヒープ上のすべてのオブジェクト (最初に連続して割り当てられたもの) を列挙します。到達可能としてマークされていないすべてのオブジェクトはガベージです。[ 32 ]これはマークフェーズです。[ 33 ]ガベージが保持するメモリは重要ではないため、空き領域とみなされます。ただし、これにより、最初に連続していたオブジェクト間に空き領域のチャンクが残ります。次に、オブジェクトが圧縮されて、管理ヒープ上の空き領域が再び連続します。[ 32 ] [ 33 ]オブジェクトの移動によって無効になったオブジェクトへの参照は、GC によって更新され、新しい場所が反映されます。[ 33 ]ガベージ コレクションが終了すると、アプリケーションが再開されます。最新バージョンの .NET Framework は、ユーザー コードとともに並行ガベージ コレクションを使用するため、バックグラウンドで実行されるため、一時停止は目立ちません。[ 34 ]
.NET Framework で使用されるガベージ コレクターも世代に基づいています。[ 35 ]オブジェクトには世代が割り当てられます。新しく作成されたオブジェクトには世代 0 のタグが付けられます。1 回のガベージ コレクションを生き残ったオブジェクトには世代 1のタグが付けられます。別のコレクションを生き残った世代 1 オブジェクトは世代 2です。フレームワークは最大で世代 2 オブジェクトを使用します。[ 35 ]世代の高いオブジェクトは、世代の低いオブジェクトよりもガベージ コレクションされる頻度が低くなります。古いオブジェクトは新しいオブジェクトよりも寿命が長い傾向があるため、これによりガベージ コレクションの効率が向上します。[ 35 ]ほとんどのコレクション実行で古いオブジェクトを無視することで、必要なチェックと圧縮操作の総数が少なくなります。[ 35 ]
アプリケーションが最初に起動されると、.NET Framework はジャストインタイム コンパイラを使用してCIL コードを実行可能コードにコンパイルし、実行可能プログラムを .NET Native Image Cache にキャッシュします。[ 36 ] [ 37 ]キャッシュのおかげで、アプリケーションは以降の起動が速くなりますが、最初の起動は通常遅くなります。最初の起動を高速化するために、開発者はNative Image Generatorユーティリティを使用して、任意の .NET アプリケーションを事前に手動でコンパイルしてキャッシュすることができます。[ 37 ]
環境に統合されているガベージコレクタは、開発者が直接制御できない予期せぬ実行遅延を引き起こす可能性があります。「大規模なアプリケーションでは、ガベージコレクタが処理する必要のあるオブジェクトの数が非常に多くなり、それらすべてを訪問して再配置するのに非常に長い時間がかかる可能性があります。」[ 38 ]
.NET Framework は、Visual Studio 2013 Update 2 の 2014 年 4 月以降、マネージド コードを介してStreaming SIMD Extensions (SSE)を呼び出すサポートを提供しています。ただし、 Mono は2009 年にMono.Simd名前空間内でバージョン 2.2 からSIMD Extensionsのサポートを提供しています。 [ 39 ] Mono のリード開発者であるMiguel de Icaza氏は、この SIMD サポートが CLR の ECMA 標準に採用されることを期待しています。[ 40 ] Streaming SIMD Extensions は、Pentium IIIの導入以来、x86 CPUで利用可能です。ARMやMIPSなどの他のアーキテクチャにも SIMD 拡張機能があります。CPU がこれらの拡張機能をサポートしていない場合、命令はソフトウェアでシミュレートされます。[ 41 ] [ 42 ]
.NET Framework は.NETのリリースまで CLI の主要な実装でした。フレームワークの一部には他の実装も存在します。ランタイム エンジンは ECMA-ISO 仕様で記述されていますが、その他の実装は特許の問題で制約を受ける可能性があります。ISO 規格には、「この文書の要素の一部が特許権の対象となる可能性があることにご注意ください。ISO は、そのような特許権の全部または一部を特定する責任を負いません。」という免責事項が含まれている場合があります。[ 43 ]オープン スタンダードで記述されておらず、著作権制限の対象となる可能性がある FCL の代替を開発するのは困難です。また、FCL の一部には Windows 固有の機能と動作があるため、Windows 以外のプラットフォームでの実装は問題になる可能性があります。
フレームワークの一部における代替実装例を以下に示します。
マイクロソフトのマネージドコードフレームワークおよびそのコンポーネントは、以下のライセンスに基づいて提供されます。
しかし、Monoには標準で必須ではないライブラリがいくつか含まれており、Tomboyなどのアプリケーションで一般的に使用されています。念のため明確にしておきますが、ASP.NETやWindows FormsのようなWindows固有のライブラリについて話しているわけではありません。代わりに、System名前空間の下にあるライブラリについて話そうと思います。これらのライブラリは、プログラマが現代のプログラミング言語で期待する一般的な機能を提供します。