我已經繼承了一個生成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();