Question

在Visul Studio的对象浏览器中，我们可以看到许多名称空间（例如System，System.Collections，System.IO）位于单个程序集mscorlib.dll中。

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

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

我的意思是，我们将所有这些名称空间作为单独的DLL（例如System.Collections.dll），我们也有mscorlib.dll。

Answer 1

程序集可以包含许多类型。这些类型可以具有任何名称空间名称程序集名称与程序集中的类型使用的名称空间名称之间没有硬关联。没有名为＆＃34; mscorlib＆＃34;的名称空间。例如，在.NET Framework中。命名空间仅用于逻辑地将类型分组为集合。

它的工作原理相反，虽然不常见，但具有相同命名空间的类型可以存在于不同的程序集中。例如，System.String位于mscorlib.dll中，System.Uri位于System.dll中。这不是你一直非常担心的事情，编译器的工作就是找出一个类型所在的汇编。它通过读取引用汇编中的元数据来实现这一点，它告诉编译器可用的类型。你稍微关心它，有时你需要添加一个引用程序集，以便编译器知道它包含的类型。通常是通过获取编译器错误提示（＆＃34;您是否缺少程序集引用？＆＃34;）并且您在MSDN Library中查找。

参考程序集过去只是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地狱。

它启用了具有不同参考组件集的概念。特别是在.NET 4.5中大量使用，增加了对WinStT的支持，即Windows Store和Phone的api。您现在有几十个的参考装配集。它们仅公开目标平台上支持的类型和方法。在基础知识中，String.Copy（）在桌面程序中受支持，但在Silverlight，Store或Phone应用程序中不受支持。因此，当您定位其中一个时，编译器会看到缺少该方法的String类型声明。帮助您避免编写无法在浏览器或手机中运行的代码。

System.Collections.dll的全部内容。它是其中一个垫片组件，它根本不包含任何代码。它隔离了平台差异，删除了.NET 1.x集合类，只是浪费了手机的宝贵存储空间或者减慢了Silverlight的下载速度。在运行时，CLR会在类上看到[TypeForwarded]属性。其中说，＆＃34;它实际上存在于mscorlib.dll中，请查看那里＆＃34;。

Answer 2

在C＃中，名称空间可以跨多个程序集，反之，一个程序集可以包含多个名称空间。

您可以自己轻松创建。

// Project.Domain.dll

namespace Project.Domain 
{
}

namespace Project.Validation 
{
}

// Project.Services.dll

namespace Project.Validation 
{
}

话虽如此，这样做并不是一个好主意。框架的规则和要求与LOB应用程序略有不同。

坚持使用指南和Visual Studio默认值（文件夹结构后面的命名空间），除非您有充分的理由去做其他事情。

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

2 个答案: