命名空间还是程序集？

我对命名空间和程序集感到非常困惑。是System.Data和System.Web命名空间或程序集？

我注意到这些被称为命名空间，并且它们同时存在于GAC_32文件夹中。那到底是什么呢？

System.Data是名称空间， System.Data.DLL（文件）是程序集。

名称空间是类型的逻辑分组（主要是避免名称冲突）。程序集可以在多个名称空间中包含类型（System.DLL包含几个...），并且单个名称空间可以分布在程序集之间（例如System.Threading）。

命名空间是属于相同功能的类的逻辑分组。所以System.Web和System.Data名称空间

MSDN将其描述为：

命名空间在C＃编程中以两种方式大量使用。首先，.NET Framework使用名称空间来组织其许多类。其次，声明您自己的名称空间可以帮助控制大型编程项目中类和方法名称的范围。

汇编是.NET运行时环境可以执行的（预编译）代码块。它包含一个或多个命名空间。.NET程序由一个或多个程序集组成。

System.Web.dll并且System.Data.dll是程序集。

MSDN将其描述为：

程序集是.NET Framework应用程序的基础。它们构成了部署，版本控制，重用，激活范围和安全权限的基本单元。程序集是类型和资源的集合，这些类型和资源被构建为可以一起工作并形成功能的逻辑单元。程序集为公共语言运行时提供了它需要了解类型实现的信息。对于运行时，程序集上下文之外不存在类型。

简而言之：

部件：

程序集提供了物理代码分组的基本单位。它是一个输出单位。它是“部署”单元和“版本控制”单元。程序集包含MSIL代码。

命名空间：

名称空间是逻辑代码分组的基本单位，它是名称的集合，每个名称中的每个名称都是唯一的，它们构成了一组类的逻辑边界。名称空间必须在Project-Properties中指定。

简而言之：

• 程序集存储为.EXE或.DLL文件。
• 命名空间是对类型名称进行分组并减少名称冲突的机会的一种方法。

提示。

程序集包含类型的集合（例如，l'assembly System包含许多名称空间，包括System，System.IO，ecc）。通常，程序集的名称与其包含的名称空间相同，但并不总是相同。

程序集和名称空间的其他示例。

程序集1（CoreAssembly.DLL）

包含名称空间Namespace1.subnamespace1

程序集2（ExtensionCoreAssembly.DLL）

包含名称空间Namespace1.subnamespace1

可以使用包含不同名称空间的程序集名称，并通过此技术将现有程序集与其他程序集一起扩展。

定义。

装配体

程序集是类型和资源的集合，形成功能的逻辑单元。.NET Framework中的所有类型都必须存在于程序集中。公共语言运行时不支持程序集外部的类型。每次使用Visual Basic .NET创建MicrosoftWindows®应用程序，Windows服务，类库或其他应用程序时，您都在构建一个程序集。每个程序集都存储为.exe或.dll文件。注意尽管从技术上讲可以创建跨多个文件的程序集，但在大多数情况下不太可能使用此技术。

命名空间

组织Visual Basic .NET代码的另一种方法是使用名称空间。命名空间不是程序集的替代，而是补充程序集的第二种组织方法。命名空间是对类型名称进行分组并减少名称冲突的机会的一种方法。名称空间可以包含其他名称空间和类型。类型的全名包括包含该类型的名称空间的组合。

链接：http：//msdn.microsoft.com/en-us/library/ms973231.aspx

它们是名称空间。程序集包含多个名称空间，例如：System.dll包含这些名称空间（以及更多）：

还有一个名称空间可能包含嵌套的名称空间，它们只是组织代码的逻辑名称。请注意，DLL文件是包含名称空间的程序集。

GAC是Global Assembly Cache。根据MSDN：

全局程序集缓存存储专门指定要由计算机上的多个应用程序共享的程序集。

因此，常用的程序集存储在中GAC，因此您无需将所有程序集文件都复制到要从项目中引用的项目目录中。存储在中的程序集GAC是“强名称”程序集。通常，当您添加对项目的程序集（不是文件Strong-Named的副本）将在您的.dll文件夹中创建。bin\Debug如果您愿意，可以使您的程序集（例如类库项目）成为“强名称”。请参见：如何：使用Strong代码签名程序集名称

其他人对此问题给出了非常好的和详尽的答案。但我想指出的是，当您不确定时，可以查看MSDN。MSDN库非常清楚地解释了任何给定类型所驻留的名称空间和程序集。它甚至说出了文件名，(in System.Data.dll)因此没有歧义。

您在GAC中看到的文件System.Data.dll是一个程序集，并且包含包括在内的名称空间System.Data。如果您在Visual Studio中查看“引用”属性，则将看到：

稍后，如果右键单击引用并在对象浏览器中选择视图，您将在该特定程序集中看到名称空间。

正如@amdluigi所说：“通常，程序集的名称与其所包含的名称空间相同，但并不总是如此”。

在Studio的对象浏览器中，上面是System.Data.dll的屏幕截图。这是在这里探讨问题的一个很好的例子。请注意，程序集中包含的大多数名称空间是System.Data或System.Data的子命名空间。

通常，将程序集名称与其中的名称空间相关联是一种好习惯。请注意，当Studio首次创建要构建程序集的项目时，项目属性之一是默认名称空间。首先，Studio为默认名称空间提供与项目本身相同的名称。如果您选择重命名项目，请务必考虑更改其默认名称空间。

还有两个额外的名称空间：Microsoft.SqlServer是可以理解的。他们不想打包在单独程序集中的某些SQL Server类型。

但是System.Xml是什么？？？？没有一个System.Xml.dll程序集。为什么还要在System.Data.dll中显示此命名空间？

请注意，程序集可以重新打开名称空间并向其添加更多内容-这正是System.Data.dll对System.Xml名称空间所做的工作。

原因是名称空间对性能的影响为零，但程序集却可以做到。如果您有1000个包含大量代码的类，则您不希望一个程序集具有非常大的内存占用。您也不希望每个组件具有一个类的1000个程序集。任何程序集都需要先加载到内存中，然后才能执行其内容。您希望程序集包含一定数量的相互关联的类，因此，一旦您的应用程序加载了程序集以获取其某个类，它就可以获取该应用程序可能需要免费使用的其他类。粒度很重要：不要太大，不要太小，恰到好处。

请注意，System.Data.dll重新打开System.Xml并仅添加一个类：XmlDataDocument。碰巧该类用于将关系数据解释为XML文档。如果您的应用程序仅使用XML，则不需要此类。如果您的应用程序处理关系数据，则可能会如此。因此，尽管XmlDataDocument继承自XmlDocument并位于System.Xml命名空间中，但它包装在System.Data.dll程序集中。

如果您具有Java的背景，而Java只有一个概念，即包，那么这一切就特别重要。在.NET中，有两个程序集和名称空间。两者是正交的。一个程序集显然可以包含多个名称空间。程序集可以重新打开一个名称空间并向其中添加更多名称-换句话说，名称空间中的类型可以跨越一个以上的程序集。

程序集是逻辑单元，命名空间的物理分组，在逻辑上将类分组。

命名空间可以跨多个程序集