我試了一下，對象瀏覽器里確實(shí)是如你所說(shuō)看不到類(lèi)的任何成員，
但沒(méi)關(guān)系，你仍可以使用該類(lèi)提供的公共屬性和方法
我測試的一個(gè)例子很簡(jiǎn)單，如下：
1。在.net中創(chuàng )建一個(gè)類(lèi)庫，test.cs文件內容如下：
using system;
namespace test
{
/// <summary>
/// class1 的摘要說(shuō)明。
/// </summary>
public class myclass
{
public myclass()
{
//
// todo: 在此處添加構造函數邏輯
//
}
public string hello()
{
return "hello,world";
}
}
}
注：工程的屬性->配置->生成->注冊為com interop設置為true,編譯該工程即可，自動(dòng)生成并
注冊了myclass類(lèi)和test類(lèi)型庫，可以通過(guò)ole/com object viewer查看，或到注冊表查看
2。建立一個(gè)vb6工程，在工程->引用...中找到test,把復選框鉤上，然后在對象瀏覽器中
可看到這個(gè)test下的類(lèi)，在窗體上放上一個(gè)button
和一個(gè)label,在button的點(diǎn)擊事件中加入如下代碼：
dim myclass1 as new myclass
label1.caption = myclass1.hello()
運行后，點(diǎn)擊button，label1顯示為“hello,world”，一切正常，可以試一試
先全注銷(xiāo)掉，然后重新注冊
gac里允許多種版本的同一程序集存在，目的是為了避免傳統的"dll地獄"，但這種方式
也有利有弊
下文轉載，作者：builder.com，希望對你有點(diǎn)用處
windows應用程序經(jīng)常受到動(dòng)態(tài)鏈接庫的拖累，這就是“dll地獄”問(wèn)題，在遇到此類(lèi)麻煩的時(shí)候，應用程序的某一個(gè)組件會(huì )被其他應用程序的不兼容組件覆蓋，結果令受到干擾的應用程序完全不能正確工作。這些問(wèn)題很難診斷出來(lái)，因為它們只有在問(wèn)題組件安裝一段時(shí)間之后才會(huì )突然冒出來(lái)。visual basic應用程序的dll地獄問(wèn)題更是臭名昭著(zhù)，因為用visual basic語(yǔ)言開(kāi)發(fā)的應用程序相比其他編程語(yǔ)言開(kāi)發(fā)的應用程序具有更大程度的外部相關(guān)性。微軟推出的.net計劃有望采用一種新型的分布單元assembly來(lái)緩和這一嚴重問(wèn)題。
assembly機制初探
從編程的角度來(lái)看，一個(gè)assembly在功能上等同于java包：它提供了相關(guān)類(lèi)的可分配庫而且定義了它們的范圍。對那些不熟悉java的人來(lái)說(shuō)，在開(kāi)發(fā)應用程序的時(shí)候，assembly之于.net無(wú)異于dll文件之于com，只不過(guò)assembly由多個(gè)文件所組成。
assembly可以通過(guò)所謂的名單實(shí)現自我文檔化，這也是它們相比dll更為優(yōu)異的一個(gè)典型特征。名單包含在assembly之內，由說(shuō)明assembly的導出類(lèi)的元數據、這些類(lèi)所需的外部依附、使用assembly所需的權限以及此類(lèi)依附的版本控制信息所組成。在.net框架內，assembly為版本、類(lèi)以及不能版本化的單個(gè)文件提供了公共名稱(chēng)。這樣就可以不必檢查多個(gè)文件以確定系統上安裝組件的版本，這也正是我們以往最感到氣惱的地方。.net的這種版本控制特性幾乎可以完全消除dll地獄病。
私有assembly和公共assembly
在缺省的情況下，.net的assembly是私有的，這意味著(zhù)它們僅能被某一個(gè)應用程序所用。私有的assembly應當被安裝到應用程序所在的文件夾或其子文件夾之一。微軟希望大多數 .net開(kāi)發(fā)人員能采用私有的assembly，而事實(shí)上它也在鼓勵人們這樣做。
但是，這樣會(huì )帶來(lái)一個(gè)潛在的問(wèn)題：用戶(hù)的硬盤(pán)內可能因為擁有同一私有assembly的多重拷貝而變得混亂不堪，這真是很具有諷刺意味，聽(tīng)起來(lái)反倒是com好象更容易解決這個(gè)問(wèn)題了。微軟則是這樣回應以上批評的：“硬盤(pán)很便宜，買(mǎi)個(gè)更大的就行了。”幸好，你可以非常方便地把私有的assembly轉為公共assembly，甚至不必重新編譯或編輯代碼。
共享之美
共享assembly和私有assembly之間的主要差別在于前者通常保存在專(zhuān)門(mén)命名的全局裝配緩存內。gac有時(shí)在微軟文檔中被稱(chēng)為global assembly store，可能是因為后者簡(jiǎn)稱(chēng)起來(lái)好聽(tīng)一些。
gac能存儲同一assembly的多個(gè)版本，這就是微軟所稱(chēng)的“肩并肩部署”功能。這一功能幾乎消除了安裝應用程序的不兼容共享組件而影響其他應用程序的可能性，這對開(kāi)發(fā)者來(lái)說(shuō)肯定是個(gè)好消息。
客戶(hù)assembly能指定它兼容哪個(gè)或者那些共享assembly的版本。如果客戶(hù)程序的版本要求不能被滿(mǎn)足，那么.net運行時(shí)就不會(huì )裝載任何服務(wù)器assembly。順便說(shuō)一句，.net的assembly版本由4位數字格式表示，形式如：主版本號.次版本號.創(chuàng )建版本號.修訂版本號。
默認地。一個(gè)assembly被認為只能兼容具有同樣主版本和次版本號的共享assembly。然而運行時(shí)裝載器卻優(yōu)先裝載相比客戶(hù)版本具有更高創(chuàng )建版本號或者修訂版本號的assembly，如果存在這樣的assembly，就會(huì )自動(dòng)地為其提供修補支持。這種缺省行為并不一定總是你所希望的，因此程序員或系統管理員可以定義定制的版本控制策略，比方說(shuō)，強迫裝載某一特定的版本或者禁用裝載器對更高創(chuàng )建版本號或者修訂版本號的assembly的裝載。
在beta 1版上，版本控制策略包含在一些xml文件內，而這些文件則要不駐留在應用程序目錄下要不就保存在windows目錄下。這些xml文件分別定義了同特定軟件相關(guān)的版本策略以及系統范圍內的版本控制策略。
命名
你可以隨意命名私有的assembly，只要其名稱(chēng)在應用程序內唯一即可。另一方面，公共assembly則需要采用某種全局唯一標識符以便.net運行時(shí)可以識別它們。com的class id和prog id已經(jīng)隨風(fēng)而逝了?，F在的共享assembly采用了所謂的strong name命名機制。strong name來(lái)源于標準的公鑰加密算法。開(kāi)發(fā)人員用一個(gè)私鑰“簽署”assembly同時(shí)提供一個(gè)公鑰供客戶(hù)assembly使用。公鑰隨后成為assembly的strong name的一部分。
采用命令行編譯器簽署assembly需要使用一些命令行指令選項，因此這也是一項比較繁重的任務(wù)。幸好，visual studio.net可以自動(dòng)地為程序員完成這些工作。
小小裝配做大事
微軟最后還是承認了dll地獄問(wèn)題的存在，而且意識到這一問(wèn)題只能通過(guò)操作系統級施加控制策略才能得以彌補。在注冊表和對com應用程序單個(gè)組件支持這方面瞎折騰一氣之后，看起來(lái)好象微軟已經(jīng)走上了正途。事實(shí)上，有了assembly機制，安裝.net應用程序完全可能變成使用xcopy命令拷貝程序那么簡(jiǎn)單！
聯(lián)系客服
