55

MS が最初にこれら 2 つのコア ライブラリを維持することを決定したのはなぜですか? スケーラビリティの問題を念頭に置いていたのかもしれませんが、最近では、両方を必要としないアプリケーションは見たことがありません。誰もこれに関する内部情報を持っていますか? 特に重要ではありませんが、何年も前から気になっていました。

PS。私は 2 つのライブラリの内容を知っています。違いも知っています。私はReflectorの大ファンです:)

4

6 に答える 6

71

私は CLR/BCL チームで働いており、あなたのメールに返信しました。以下に貼り付けます。

スタックオーバーフローに関するジャレッドの答えは正しいです。彼が言及した理由により、mscorlib.dll は CLR に密接にバインドされています。mscorlib.dll 自体には (Scott が示唆するように) ネイティブ コードは含まれていませんが、CLR を直接呼び出す必要がある場所が多数あることに注意してください。そのため、CLR と mscorlib は一緒にバージョン管理する必要があります。

一方、System.dll は CLR に厳密にはバインドされていません (ランタイムへの呼び出しは必要ありません)。System.dll は、mscorlib.dll より上位層にあると見なされます。これらのアセンブリを 2 つの別個のレイヤーに配置すると、柔軟性が向上し、System.dll を CLR/mscorlib.dll バージョンとは別にバージョン管理することが容易になります (必要に応じて)。理論的には、CLR/mscorlib のバージョンを変更しなくても、System.dll に変更を加えて機能を追加することができます。また、この分離により、これらの異なるレイヤー内のコンポーネント間の依存関係ルールの管理が容易になります。

Scott が言及しているように、mscorlib には多くの「オプション」のものがあるようです。これは主に歴史的な理由によるものであり、あるものは単に他のものによって必要とされるためです。たとえば、System.IO.IsolatedStorage を mscorlib に含める必要がある技術的な理由はありませんが、そのようなバージョン管理/階層化の問題について実際に考える前に、たまたま 1.0 で追加された場所です。また、mscorlib の他のコードには基本的なリスト コレクションが必要なため、List は mscorlib にあります。

長期的には、mscorlib の「オプション」の量を可能な限り減らしたいと考えています。mscorlib から何かをプッシュするか、必要最小限の型 (System.Object、System.Int32 など) だけを含む新しい、よりコアなアセンブリを作成して、マネージ コードを機能させます。これにより、「オプション」のものに新しいイノベーションを追加する柔軟性が得られ、ランタイムを変更することなく、さまざまな .NET Framework SKU (.NET クライアント プロファイル、Silverlight など) を簡単に作成できるようになります。

これが役立つことを願っています！

ありがとう、ジャスティン

于 2009-01-01T00:03:42.333 に答える
40

Mscorlib には、ネイティブ コードとマネージド コードの両方が含まれています。

とりわけ、System.Object 実装が含まれています。これは、すべてが機能するために常に存在する必要があります。

これは、CLR がすべてのマネージ プロセス内にロードする必要がある唯一のアセンブリであるという特徴があります。

もともと、多くの「オプション」のもの (アプリを実行するために技術的に必須ではないもの) は、誰もが使用する可能性が高いものだったため、mscorlib に入れられました。これには、HashTable や List などが含まれます。

これにより、パフォーマンスが向上しました。誰もが何かを使いたいと思うなら、それを誰もがロードしなければならないアセンブリの中に入れるのは理にかなっています。そうすれば、さまざまなアセンブリ全体をまとめてバインドするために時間を無駄にする必要はありません。

system.dll 内のものは、基本的に、mscorlib に含めるのに「ふさわしくない」ものすべてでした。

しかし、この傾向は逆転し始めています。CLR は、mscorlib のサイズを縮小するための努力を行っています。たとえば、Silverlight の多くのものが削除されました (ダウンロード サイズを縮小するため)。

V4 (およびそれ以降のバージョン) では、この種のことをもっと行っているのではないかと思いますが、詳細についてはわかりません。

于 2008-12-31T10:36:01.513 に答える
16

スコットの答えを拡張します。

CLR の特定のバージョンは、mscorlib.dll の特定のバージョンに強く結び付けられています。これは非常に多くの点で特別なDLL です。CLR ランタイムでは、特定の型/メソッドを使用できる必要があり、実際のコード ベースで定義された多くのメソッドを実装します。この関係を管理する複雑さは、CLR のバージョンと mscorlib のバージョンとの間に壊れないリンクを持つことによって軽減されます。

于 2008-12-31T14:45:48.997 に答える
6

プロジェクトの References ノードをよく見てください。そこに mscorlib.dll がリストされていることはありません。これは特別です。言語構文を機能させるために必要な型が含まれているため、どのコンパイラにも必要です。System.Array、System.Int32、System.String、System.Exception など。

System.dll に依存しないプログラムを作成することはできますが (困難ですが)、mscorlib.dll に依存しないプログラムを作成することはできません。

于 2008-12-31T10:29:32.070 に答える
1

言及されたネイティブ/管理されたものはもっともらしいように聞こえますが、私はまだ完全に確信していません。いずれにせよ、MSはmscorlib.dllをシステムに必要なコアライブラリと見なしているようですが、System.dllにはプログラマー向けのコア機能が含まれています。

これと同じ質問をBCLチームにメールで送信しました。誰かが答えられるなら...（もし？）私が答えを受け取ったら、ここに投稿します。これまでの回答ありがとうございます！

于 2008-12-31T14:27:09.313 に答える
0

これは推測に過ぎませんが、mscorlib.dll には、CLR ランタイムにとって重要な C コードや、.NET アセンブリ、または混合モード コードが含まれている可能性があります。System.dll はおそらくすべて管理されています。

于 2008-12-31T10:18:18.007 に答える