mscorlib.dll＆amp; System.dll

StackOverflow https://stackoverflow.com/questions/402582

  •  03-07-2019
  •  | 
  •  

質問

なぜこれらの2つのコアライブラリを維持することをMSが最初に決定したのですか？多分彼らはいくつかのスケーラビリティの問題を念頭に置いていたかもしれませんが、今日では、両方を必要としないタイプのアプリケーションを見ることはありません。これに関する内部情報はありますか？それほど重要ではありませんが、長年私の心に残っていました。

PS。私は2つのライブラリの内容を知っています。違いを知っています- Reflector :) 2つの分離が実際にどのように使用されるのか疑問に思います。

役に立ちましたか？

解決

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

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

すべての管理対象プロセス内にCLRをロードする必要がある唯一のアセンブリであるという区別があります。

元々、多くの「オプション」もの（技術的にアプリを実行するために必要ではないもの）は、すべての人が使用する可能性が非常に高いものであるため、mscorlibに入れられました。これには、HashTableやListなどが含まれます。

これにより、パフォーマンスが向上しました。誰もが何かを使用したい場合、すべての人がロードしなければならないアセンブリ内にそれを置くことは理にかなっています。そうすれば、さまざまなアセンブリをまとめて束ねて時間を無駄にする必要はありません。

system.dllの内容は、基本的に「価値のある」ものではないすべてのものでした。 mscorlibに含まれています。

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

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

他のヒント

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

  

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

     一方、

System.dllは   CLRに緊密にバインドされています（そうではありません   ランタイムへの呼び出しが必要です）。   System.dllは   mscorlib.dllよりも上位のレイヤー。   これらのアセンブリを2つにまとめる   別々のレイヤーでより多くのことができます   柔軟性、簡単に   バージョンSystem.dllとは別に   CLR / mscorlib.dllバージョン（必要に応じて   そうするには）。理論的には、   機能の変更と追加   回転せずにSystem.dll   CLR / mscorlibバージョン。分離   また、管理が容易になります   コンポーネント間の依存関係ルール   これらの異なるレイヤー。

     

スコットが言及しているように、   多くの「オプション」があります。でのもの   mscorlib。これは主に   歴史的な理由と   物事は他の人に必要なだけです   もの。たとえば、ありません   技術的な理由   System.IO.IsolatedStorageは   mscorlibで、しかしそれはちょうどそれです   たまたま、1.0で追加されました。   本当にそんなことを考えた   バージョン管理/階層化の問題。また、   リストはmscorlibにあります   mscorlibのコードには、   基本的なリストのコレクション。

     

長期的には、   「オプション」の量; mscorlibのもの   できるだけ。どちらかによって   mscorlibからデータをプッシュする、または   新しい、よりコアなアセンブリの作成   最低限必要なものだけが含まれている   必要なタイプ（例えば、System.Object、   System.Int32など）を管理対象にする   コード作業。これにより、   新しいイノベーションを追加する柔軟性   「オプション」もの、そしてそれを作ります   異なる.NETを簡単に作成できます   フレームワークSKU（例：.NETクライアント   プロファイル、Silverlightなど）、なし   ランタイムを改訂する必要があります。

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

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

スコットの答えを拡大する。

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

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

System.dllに依存関係のないプログラムを作成することはできますが（難しいことですが）、mscorlib.dllに依存しないプログラムを作成することはできません

前述のネイティブ/管理されたものはもっともらしいが、私はまだ完全には納得していない。いずれの場合でも、MSはmscorlib.dllを system に必要なコアライブラリと見なしているようですが、System.dllには programmers のコア機能が含まれています。

この同じ質問をBCLチームにメールで送信しました。 誰でもが回答できる場合...回答を受け取った場合（もしそうですか？）、ここに投稿します。これまでの回答に感謝します！

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top