mscorlib.dll 및 System.dll

mscorlib.dll 및 System.dll

---

MS가 원래이 두 개의 개별 코어 라이브러리를 유지하기로 결정한 이유는 무엇입니까? 확장 성 문제를 염두에 두었을 수도 있지만, 요즘에는 둘 다 필요하지 않은 어떤 유형의 애플리케이션도 본 적이 없습니다. 누구든지 이것에 대한 내부 정보가 있습니까? 별로 중요하지는 않지만 몇 년 동안 마음 속에있었습니다.

추신. 나는 두 개의 libs에 무엇이 있는지 알고, 차이점을 알고 있습니다. 저는 Reflector 의 열렬한 팬입니다. :) 둘의 분리가 어떤 실용적인 용도인지 궁금합니다.

---

Mscorlib에는 네이티브 코드와 관리 코드가 모두 포함되어 있습니다.

무엇보다도 모든 것이 작동하려면 항상 존재해야하는 System.Object 구현이 포함되어 있습니다.

CLR이 모든 관리되는 프로세스 내에로드되어야하는 유일한 어셈블리라는 차이점이 있습니다.

원래 많은 "선택적"항목 (기술적으로 앱을 실행하는 데 필요하지 않은 항목)이 mscorlib에 포함되었습니다. 왜냐하면 모두가 사용할 가능성이 높은 항목 이었기 때문입니다. 여기에는 HashTable 및 List와 같은 항목이 포함됩니다.

이것은 성능 향상을 가져 왔습니다. 모든 사람이 무언가를 사용하고 싶다면 모두가로드해야하는 어셈블리 안에 넣는 것이 좋습니다. 그러면 다양한 어셈블리를 묶는 데 시간을 낭비 할 필요가 없습니다.

system.dll의 내용은 기본적으로 mscorlib에 포함될 "가치가없는"모든 것입니다.

그러나 이러한 추세는 역전되기 시작했습니다. CLR은 mscorlib의 크기를 줄이기 위해 노력하고 있습니다. 예를 들어 Silverlight에서는 다운로드 크기를 줄이기 위해 많은 항목이 제거되었습니다.

나는 그들이 V4 (및 이후 버전)에 대해 이런 종류의 일을 더 많이 할 것이라고 생각하지만 세부 사항에 대해서는 확신하지 못합니다.

---

저는 CLR / BCL 팀에서 일하며 귀하의 이메일에 답장했습니다. 여기에 붙여 넣었습니다.

Stack Overflow에 대한 Jared의 답변이 맞습니다. mscorlib.dll은 그가 언급 한 이유로 CLR에 밀접하게 연결되어 있습니다. mscorlib.dll 자체에는 네이티브 코드가 포함되어 있지 않지만 (Scott이 제안한대로) CLR을 직접 호출해야하는 곳이 많이 있습니다. 따라서 CLR과 mscorlib는 함께 버전을 관리해야합니다.

반면에 System.dll은 CLR에 밀접하게 연결되어 있지 않습니다 (런타임에 대한 호출이 필요하지 않음). System.dll이 mscorlib.dll보다 상위 계층에 있다고 간주합니다. 이러한 어셈블리를 두 개의 개별 계층에두면 유연성이 향상되어 CLR / mscorlib.dll 버전과 별도로 System.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 Client Profile, Silverlight 등)를 더 쉽게 만들 수 있습니다.

이게 도움이 되길 바란다!

고마워, 저스틴

---

Scott의 대답을 확장합니다.

특정 버전의 CLR은 특정 버전의 mscorlib.dll과 밀접하게 연결되어 있습니다. 그것은이다 특별한 매우 여러 가지면에서 DLL. CLR 런타임은 특정 유형 / 방법을 사용할 수 있어야하며 실제 코드 기반에 정의 된 많은 방법을 구현합니다. 이 관계를 관리하는 복잡성은 CLR 버전과 mscorlib 버전간에 끊기지 않는 연결을 통해 감소됩니다.

---

프로젝트의 참조 노드를 잘 살펴보십시오. 거기에 나열된 mscorlib.dll을 찾을 수 없습니다. 언어 구문을 작동시키는 데 필요한 유형이 포함되어 있기 때문에 모든 컴파일러가 필요합니다. System.Array, System.Int32, System.String, System.Exception 등

System.dll에 종속되지 않는 프로그램을 작성할 수 있지만 (어려울지라도) mscorlib.dll에 종속되지 않는 프로그램은 작성할 수 없습니다.

---

언급 된 네이티브 / 관리되는 것은 그럴듯하게 들리지만 여전히 완전히 확신하지는 않습니다. 어쨌든 MS는 mscorlib.dll을 시스템에 필요한 핵심 lib로 보는 것처럼 보이지만 System.dll에는 프로그래머를 위한 핵심 기능이 포함되어 있습니다 .

이 질문을 BCL 팀에 이메일로 보냈습니다. 누구든지 답변 할 수 있다면 ... 답변을 받으면 여기에 게시하겠습니다. 지금까지 답변 해 주셔서 감사합니다!

---

이것은 추측 일 뿐이지 만 mscorlib.dll에는 .NET 어셈블리 또는 혼합 모드 코드 일뿐만 아니라 CLR 런타임에 중요한 일부 C 코드가있을 수도 있습니다. System.dll은 아마도 모두 관리됩니다.

참조 URL : https://stackoverflow.com/questions/402582/mscorlib-dll-system-dll