.net が型を解決する方法に興味があります。現在のアセンブリまたは参照されているアセンブリにない using ステートメントまたは完全修飾型を含むプログラムをコンパイルできないため、コンパイル時コンポーネントがあることはわかっています。エラーが発生するのはコンパイラなのか、それとも proj ファイルで参照が見つからない場合にビルド エラーをスローするのはビジュアル スタジオなのだろうか?
また、実行時に.netがアセンブリをどのように見つけるのか疑問に思っています。.net は、そのアセンブリから型を初めて実行したときにアセンブリを読み込む JIT コンパイラを使用していることを知っています。タイプと検索順序の検索がどのように行われるのか興味があります。アセンブリ マニフェストは、参照されたアセンブリ (ASP.NET の web.config ファイルなど) を探す場所をランタイムに正確に伝えていますか? ブログ投稿、本、仕様などへのリンクは大歓迎です。
認識されない識別子を使用したときに表示されるエラー メッセージの最終的な原因は、コンパイラです。IntelliSense から早期警告が表示され、識別子名の下に赤い波線が表示されます。
コンパイラは、ソース コードから生成するアセンブリのメタデータに、アセンブリ、名前空間、および型名を記録します。アセンブリの場合、表示名 (System など)、参照アセンブリで見つかった [AssemblyVersion]、厳密な名前のアセンブリに関連する値である PublicKeyToken を記録します。
実行時に、これら 3 つのアセンブリ プロパティだけでアセンブリを検索するのは CLR の仕事です。ジッターは、コードを生成する必要があるときに CLR にそれを見つけるように要求するものです。それについては、通常のルックアップ ルールのオーバーライドに関連するいくつかのあいまいな詳細があります。それらは、.NET または MSDN に関する優れた本に記載されています。詳細については、このMSDN の記事を参照してください。
通常の方法では、最初に、アセンブリの保管場所であり、すべての .NET Framework アセンブリが格納される場所である GAC を調べます。GAC は、名前が同じでバージョンが異なる複数のアセンブリを格納できるため、特別な機能を備えています。これは、強力な DLL Hell 対策です。そこに見つからない場合は、これら 3 つのプロパティとアーキテクチャの完全一致を使用して、EXE が格納されているディレクトリを検索し、表示名が一致する場合は一致を受け入れます。すべてのアセンブリ プロパティが一致し、型が同じ名前空間と型名で返される場合は、すべて問題ありません。