Abb*_*ghi 1 .net dll assemblies namespaces
在Visul Studio的对象浏览器中,我们可以看到许多名称空间(例如System,System.Collections)System.IO都位于单个程序集中mscorlib.dll.
我想知道它们是如何在多个组件中分开的:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework
我的意思是,我们将所有这些名称空间作为单独的DLL(例如System.Collections.dll),我们也有mscorlib.dll.
程序集可以包含许多类型.这些类型可以具有任何名称空间名称 程序集名称与程序集中的类型使用的名称空间名称之间没有硬关联.例如,.NET Framework中没有名为"mscorlib"的命名空间.命名空间仅用于将类型逻辑分组到集合中.
它的工作原理相反,虽然不常见,但具有相同命名空间的类型可以存在于不同的程序集中.例如,System.String位于mscorlib.dll中,System.Uri位于System.dll中.这不是你一直非常担心的事情,编译器的工作就是找出一个类型所在的汇编.它通过读取引用汇编中的元数据来实现这一点,它告诉编译器可用的类型.你稍微关心它,有时你需要添加一个引用程序集,以便编译器知道它包含的类型.通常是通过获取编译器错误("您是否缺少程序集引用？")并查看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]属性.其中说,"它实际上存在于mscorlib.dll中,请查看那里".