命名空间或大会?
我在名称空间和程序集之间感到非常困惑。 是System.Data
和System.Web
命名空间或组件?
我注意到这些被称为命名空间,同时它们存在于GAC_32
文件夹中。 那么他们究竟是什么?
System.Data
是一个命名空间 , System.Data.DLL
(该文件)是一个程序集 。
名称空间是types的逻辑分组(主要是为了避免名称冲突)。 一个程序集可以包含多个名称空间中的types( System.DLL
包含几个…),并且一个单独的名称空间可以遍布在程序集中(例如System.Threading
)。
命名空间是属于相同function的类的逻辑分组。 所以System.Web
和System.Data
是命名空间
MSDN将其描述为:
命名空间在C#编程中有两种使用方式。 首先,.NET Framework使用命名空间来组织其多个类。其次,声明自己的命名空间可以帮助控制更大的编程项目中的类和方法名称的范围。
程序集是可以由.NET运行时环境执行的(预编译的)代码块。 它包含一个或多个名称空间。 一个.NET程序由一个或多个程序集组成。
System.Web.dll
和System.Data.dll
是程序集。
MSDN将其描述为:
程序集是.NET Framework应用程序的构build块。 它们构成了部署,版本控制,重用,激活范围和安全权限的基本单位。 程序集是构build在一起工作并形成function逻辑单元的types和资源的集合。 程序集为公共语言运行时提供了需要了解types实现的信息。 对于运行时,types不存在于程序集的上下文之外。
简而言之:
部件:
一个程序集提供了一个物理代码分组的基本单元。它是一个输出单元。 它是一个部署单元和一个版本控制单元。 程序集包含MSIL代码。
命名空间:
命名空间提供了一个逻辑代码分组的基本单位。它是一个名称集合,每个名称中都是唯一的。它们构成一组类的逻辑边界。命名空间必须在Project-Properties中指定。
它们是名称空间。组件包含多个名称空间。例如: System.dll
包含这些名称空间(以及更多):
另外一个命名空间可能包含嵌套命名空间。它们只是用于组织代码的逻辑名称。只要注意, DLL
文件是包含命名空间的程序集。
GAC
是全局程序集caching 。 根据MSDN:
全局程序集caching存储专门指定为由计算机上的多个应用程序共享的程序集。
因此,常用的程序集存储在GAC
,因此不需要将所有程序集文件复制到您的项目引用的项目目录中。存储在GAC
中的程序集是强名称程序集。通常,当您添加引用从您的项目不是Strong-Named
一个程序集Strong-Named
您的.dll
文件的副本将创build您的bin\Debug
夹..如果您希望您可以使您的程序集(例如类库项目)Strong-Named.See : 如何:使用强名称签署程序集
您在GAC中看到的文件是System.Data.dll
,它是一个程序集,包含名称空间,包括System.Data
。 如果您在Visual Studio中查看引用属性,那么您将看到:
稍后,如果右键单击引用并在对象浏览器中select视图,则会在该特定程序集中看到名称空间。
简而言之:
- 程序集存储为.EXE或.DLL文件。
- 命名空间是对types名称进行分组并减less名称冲突的一种方法。
提示。
一个程序集包含一个types集合(例如,l'assembly系统包含许多名称空间,包括System,System.IO,ecc)。 通常,程序集的名称与其包含的名称空间相同,但并非总是如此。
程序集和命名空间的其他例子。
程序集1( CoreAssembly.DLL )
包含名称空间Namespace1.subnamespace1
程序集2( ExtensionCoreAssembly.DLL )
包含名称空间Namespace1.subnamespace1
可以使用包含不同名称空间的程序集名称,并使用此技术将其他程序集扩展到现有程序集。
定义。
大会
程序集是形成function的逻辑单元的types和资源的集合。 .NET Framework中的所有types都必须存在于程序集中; 公共语言运行时不支持程序集以外的types。 每次使用Visual Basic .NET创buildMicrosoftWindows®应用程序,Windows服务,类库或其他应用程序时,您都在构build一个程序集。 每个程序集都存储为.exe或.dll文件。 注意尽pipe创build跨多个文件的程序集在技术上是可行的,但在大多数情况下,您不太可能使用此技术。
命名空间
另一种组织Visual Basic .NET代码的方法是使用名称空间。 命名空间不是组件的替代品,而是补充组件的第二种组织方法。 命名空间是对types名称进行分组并减less名称冲突的一种方法。 名称空间可以包含其他名称空间和types。 types的全名包含包含该types的名称空间的组合。
链接: http : //msdn.microsoft.com/en-us/library/ms973231.aspx
其他人对这个问题给出了非常好的和详细的答案。 但是我想指出,当你不确定的时候,你可以看看MSDN。 MSDN库非常清楚简单地解释了任何给定types所在的名称空间和程序集 。 它甚至说文件的名称(in System.Data.dll)
所以没有歧义。
正如@amdluigi所说,“通常,程序集的名称与其包含的名称空间相同,但并不总是”。
在Studio的对象浏览器中有一个System.Data.dll的截图。 这是一个很好的例子来探讨这里的问题。 请注意,程序集中包含的大部分名称空间都是System.Data或System.Data的子名称空间。
一般来说,将程序集名称与其中的名称空间相关联是一个很好的做法。 请注意,当Studio首先创build一个项目来构build程序集时,其中一个项目属性是默认的名称空间。 开始时,Studio给出的默认名称空间与项目本身的名称相同。 如果您select重命名项目,请考虑更改其默认名称空间。
有两个额外的命名空间:Microsoft.SqlServer是可以理解的。 一些SQL Servertypes,他们不想在一个单独的程序集中打包。
但System.Xml是什么? 有一个System.Xml.dll程序集。 为什么这个命名空间也出现在System.Data.dll中?
请注意,程序集可以重新打开命名空间并添加更多内容 – 这正是System.Data.dll在System.Xml命名空间中所做的。
原因是命名空间没有性能影响,但程序集非常重要。 如果您有1000个具有大量代码的类,则不需要具有非常大的内存占用空间的程序集。 你也不想每个1000个程序集都有一个类。 任何程序集在执行内容之前都需要加载到内存中。 您希望程序集包含合理数量的相关类,因此,一旦您的应用程序加载了程序集以获取其中一个类,就会得到应用程序可能需要的其他类。 粒度很重要:不要太大,不要太小,恰到好处。
注意System.Data.dll重新打开System.Xml,并添加一个类:XmlDataDocument。 碰巧这个类被用来把关系数据解释为一个XML文档。 如果您的应用程序只使用XML,则不需要此类。 如果您的应用程序处理关系数据,它可能会。 因此,虽然XmlDataDocument从XmlDocumentinheritance,并且位于System.Xml命名空间中,但它被打包在System.Data.dll程序集中。
所有这一切,如果你有一个Java的背景,那里只有一个概念,那么这个包就特别重要。 在.NET中有两个,程序集和命名空间。 两者是正交的。 程序集显然可以包含多个名称空间。 一个程序集可以重新打开一个名称空间并添加更多内容 – 换句话说,名称空间中的types可能跨越多个程序集。