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