.net - 为什么在 .NET 框架中有一些命名空间有几个与之关联的 DLL？

Question

在 Visul Studio 的 Object Browser 中，我们可以看到很多命名空间，如 System , System.Collections , System.IO有位于单个程序集mscorlib.dll .

我想知道它们是如何在多个程序集中分开的:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework

我的意思是，我们将所有这些命名空间作为一个单独的 DLL(例如 System.Collections.dll)，我们还有 mscorlib.dll也。

Answer 1

一个程序集可以包含多种类型。这些类型可以有任何命名空间名称。程序集名称和程序集中的类型使用的命名空间名称之间没有硬关联。例如，.NET Framework 中没有名为“mscorlib”的命名空间。命名空间仅用于在逻辑上将类型分组为集合。

它也以相反的方式工作，尽管不太常见，但具有相同命名空间的类型可以存在于不同的程序集中。例如，System.String 存在于 mscorlib.dll 中，System.Uri 存在于 System.dll 中。这不是你曾经深切担心的事情，编译器的工作是找出类型所在的程序集。它通过读取引用程序集中的元数据来做到这一点，它告诉编译器哪些类型可用。您确实有点关心它，有时您需要添加一个引用程序集，以便编译器知道它包含的类型。通常通过收到编译器错误(“您是否缺少程序集引用？”)以及您在 MSDN 库中查找来提示。

引用程序集曾经只是 GAC 中程序集的副本，存储在 c:\windows\microsoft.net\framework 中。尽管获得安全或错误修复更新使 GAC 中的副本与引用程序集不同是很常见的。这是引用程序集的点，它们将您与运行时程序集中的更改隔离开来。

这在 .NET 4.0 中发生了变化，那里的引用程序集与 GAC 中的引用程序集非常不同。它们只包含元数据，即编译器关心的部分，但根本不包含代码。这将运行时程序集中的更改隔离得更厉害，Microsoft 使用它向 .NET 4.0 提供了多个更新。大多数程序员基本上没有注意到，.NET Framework 4.01、4.02 和 4.03 版在他们没有注意到的情况下滑入他们的计算机，也没有破坏他们的程序。与早期版本中的一些事故不同，添加 WaitHandle.WaitOne(Int32) 重载的情况是臭名昭著的。在 .NET 2 SP2 中添加并在未安装 SP2 的机器上运行时破坏程序。纯粹的 DLL hell 。

并且它启用了具有不同引用程序集集的概念。特别是在 .NET 4.5 中大量使用，增加了对 WinRT、Windows Store 和 Phone 的 api 的支持。您现在拥有数十个引用装配集。它们只公开目标平台支持的类型和方法。归根结底，String.Copy() 在桌面程序中受支持，但在 Silverlight、Store 或 Phone 应用程序中不受支持。因此，当您定位其中之一时，编译器会看到缺少该方法的 String 类型声明。帮助您避免编写无法在浏览器或手机中运行的代码。

这就是 System.Collections.dll 的全部内容。它是那些 shim 程序集之一，它根本不包含任何代码。它隔离了平台差异，删除了 .NET 1.x 集合类，只会浪费宝贵的手机存储空间或减慢 Silverlight 的下载速度。在运行时，CLR 会看到该类的 [TypeForwarded] 属性。其中说，“它实际上存在于 mscorlib.dll 中，去那边看看”。