我继承了一个生成 2 个 DLLS 的 VB.net 项目：一个用于 Web 应用程序，另一个用于“业务层”。这是针对较大网站的子应用程序。 （使用 VS2005）。
问题是 DLL 和命名空间结构有些不对劲，我想知道是否有任何性能影响。
主要的网络应用程序是“Foo”，并生成 Foo.dll。 Foo.dll 包含命名空间 App.Foo，其中包含所有页面、用户控件等的类。
还有一个项目“FooLib”可以生成 FooLib.dll。 FooLib.dll 还包含一个 App.Foo 命名空间，其中包含一堆类定义。还有一些其他命名空间，如 App.Foo.Data、App.Foo.Logic 等。
这有什么问题吗？运行时如何跨多个 DLL 找到一个类？
【问题讨论】：
标签： .net asp.net namespaces
不，这没有什么问题。
考虑一下，我使用了许多自定义类库，几乎每个类库都具有以下命名空间结构：
.Web.UI.Controls。
这与 System.Web.UI.Controls 类似（MS 建议作为最佳实践）..
问题是编译器会知道在您分配的尽可能多的 DLL 中存在正确的命名空间（它将在两个 DLL 中搜索它）。我会犹豫以这种方式使它们完全相同的唯一原因是因为可能的 DEVELOPER 混淆。另一个原因是，如果每个命名空间都有一个名称完全相同的类 - 这将抛出编译器错误，直到使用完全命名的命名空间声明解决它。
这也是您可以为命名空间命名的部分原因。别名将解决这两个概念。它的结构如下所示：
using Foo.App.Foo;
using FooLib = FooLib.App.Foo;
因此，如果您在 Foo.App.Foo 和 FooLib.App.Foo 中都有一个 Bar 类，以访问您将使用的应用程序版本：
bar x = new bar();
对于您要使用的库版本：
FooLib.bar x = new FooLib.bar();
【讨论】：
当您的程序被编译时，完整的类型名称与“证据”一起包含在内。该证据包括程序集的名称和版本信息。否则它不会知道您是否想要 1.0 或 1.1 或 2.0 版本的类。这个相同的系统允许它在不同程序集中的相同命名空间中找到不同的类。
就性能而言，影响不大。有利的一面是，这意味着您的某些内容可以在不同时间加载，这通常是您想要的效果。
命名空间是以一种易于查找的方式打包功能。程序集是以一种高效加载的方式打包功能。有时它们并不相同。
【讨论】：
这并没有错，唯一可能的问题可能是 1) 看到“App.Foo.Something”的开发人员可能不知道要查看哪个程序集 2) 如果在两者中使用相同的名称，则应用程序编译针对 (至少在 c# 中）会得到关于类型名称不明确的错误。
对于运行时，类型由程序集和名称指定 - 命名空间只是类型名称的一部分。因此，运行时查找类型不会有任何问题 - 当您编译有关要在哪个程序集中编译的信息时。
【讨论】：
命名空间不存在于 IL 级别。运行时从一个伪全限定名中查找一个类，即以它的命名空间为前缀的类型的名称。
我认为这样做不存在技术问题，事实上 .NET Framework 本身有时会跨多个物理程序集使用相同的命名空间。
命名空间不是 .NET 世界的一等公民，对此我感到遗憾。
【讨论】：
不，重叠的命名空间没有任何问题。看看覆盖了许多命名空间的 .net 框架本身。
【讨论】：