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