微軟Windows應用程序經常受到動態鏈接庫的拖累，這就是“DLL地獄”問題，在遇到此類麻煩的時候，應用程序的某一個組件會被其他應用程序的不兼容組件覆蓋，結果令受到干擾的應用程序完全不能正確工作。這些問題很難診斷出來，因爲它們只有在問題組件安裝一段時間之後纔會突然冒出來。Visual Basic應用程序的DLL地獄問題更是臭名昭著，因爲用Visual Basic語言開發的應用程序相比其他編程語言開發的應用程序具有更大程度的外部相關性。微軟推出的.NET計劃有望採用一種新型的分佈單元assembly（裝配）來緩和這一嚴重問題。
assembly機制初探
從編程的角度來看，一個assembly在功能上等同於Java包：它提供了相關類的可分配庫而且定義了它們的範圍。對那些不熟悉Java的人來說，在開發應用程序的時候，assembly之於.NET無異於DLL文件之於COM，只不過assembly由多個文件所組成。
Assembly可以通過所謂的名單（manifest）實現自我文檔化，這也是它們相比DLL更爲優異的一個典型特徵。名單包含在assembly之內，由說明assembly的導出類的元數據、這些類所需的外部依附、使用assembly所需的權限以及此類依附的版本控制信息所組成。在.NET框架內，assembly爲版本、類以及不能版本化的單個文件提供了公共名稱。這樣就可以不必檢查多個文件以確定系統上安裝組件的版本，這也正是我們以往最感到氣惱的地方。.NET的這種版本控制特性幾乎可以完全消除DLL地獄病。
私有assembly和公共assembly
在缺省的情況下，.NET的assembly是私有的，這意味着它們僅能被某一個應用程序所用。私有的assembly應當被安裝到應用程序所在的文件夾或其子文件夾之一。微軟希望大多數 .NET開發人員能採用私有的assembly，而事實上它也在鼓勵人們這樣做。
但是，這樣會帶來一個潛在的問題：用戶的硬盤內可能因爲擁有同一私有assembly的多重拷貝而變得混亂不堪，這真是很具有諷刺意味，聽起來反倒是COM好象更容易解決這個問題了。微軟則是這樣迴應以上批評的：“硬盤很便宜，買個更大的就行了。”幸好，你可以非常方便地把私有的assembly轉爲公共assembly，甚至不必重新編譯或編輯代碼。
共享之美
共享assembly和私有assembly之間的主要差別在於前者通常保存在專門命名的全局裝配緩存（簡稱GAC）內。GAC有時在微軟文檔中被稱爲Global Assembly Store，可能是因爲後者簡稱起來好聽一些。
GAC能存儲同一assembly的多個版本，這就是微軟所稱的“肩並肩部署”功能。這一功能幾乎消除了安裝應用程序的不兼容共享組件而影響其他應用程序的可能性，這對開發者來說肯定是個好消息。
客戶assembly能指定它兼容哪個或者那些共享assembly的版本。如果客戶程序的版本要求不能被滿足，那麼.NET運行時就不會裝載任何服務器assembly。順便說一句，.NET的assembly版本由4位數字格式表示，形式如：主版本號.次版本號.創建版本號.修訂版本號。
默認地。一個assembly被認爲只能兼容具有同樣主版本和次版本號的共享assembly。然而運行時裝載器卻優先裝載相比客戶版本具有更高創建版本號或者修訂版本號的assembly，如果存在這樣的assembly，就會自動地爲其提供修補支持。這種缺省行爲並不一定總是你所希望的，因此程序員或系統管理員可以定義定製的版本控制策略，比方說，強迫裝載某一特定的版本或者禁用裝載器對更高創建版本號或者修訂版本號的assembly的裝載。
在Beta 1版上，版本控制策略包含在一些XML文件內，而這些文件則要不駐留在應用程序目錄下要不就保存在Windows目錄下。這些XML文件分別定義了同特定軟件相關的版本策略以及系統範圍內的版本控制策略。
命名
你可以隨意命名私有的assembly，只要其名稱在應用程序內唯一即可。另一方面，公共assembly則需要採用某種全局唯一標識符以便.NET運行時可以識別它們。COM的Class ID和Prog ID已經隨風而逝了。現在的共享assembly採用了所謂的strong name命名機制。Strong name來源於標準的公鑰加密算法。開發人員用一個私鑰“簽署”assembly同時提供一個公鑰供客戶assembly使用。公鑰隨後成爲assembly的strong name的一部分。
採用命令行編譯器簽署assembly需要使用一些命令行指令選項，因此這也是一項比較繁重的任務。幸好，Visual Studio.NET可以自動地爲程序員完成這些工作。
小小裝配做大事
微軟最後還是承認了DLL地獄問題的存在，而且意識到這一問題只能通過操作系統級施加控制策略才能得以彌補。在註冊表和對COM應用程序單個組件支持這方面瞎折騰一氣之後，看起來好象微軟已經走上了正途。事實上，有了assembly機制，安裝.NET應用程序完全可能變成使用Xcopy命令拷貝程序那麼簡單！