AssemblyInfo.cs的作用


總結:用來設置項目生成的dll的常規信息。(如版本、版權等等)它就相當於一個資源文件,存放資源信息。

http://www.cnblogs.com/xuyuantao/articles/927285.html

AssemblyInfo.cs主要用來設定生成的有關程序集的常規信息dll文件的一些參數請看以下具體說明: 
//備注: 
[assembly:AssemblyDescription("用最強的搶劫類寫成!")] 
//產品名稱 
[assembly:AssemblyProduct("產品名稱 ")] 
//公司 
[assembly:AssemblyCompany("公司")]
//合法商標 
[assembly:AssemblyTrademark("合法商標")];
//內部名稱 
[assembly:AssemblyCulture("")]
//設計者 
[assembly:AssemblyDescription("設計者 ")] 
//版權 
[assembly:AssemblyCopyright("版權")] 
//配置文件 
[assembly:AssemblyConfiguration("Configuration")] 
//產品版品: 可指定,如下 
// 程序集的版本信息由下列 4 個值組成: // 
// 主版本 
// 次版本 
// 內部版本號 
// 修訂號 // 
// 您可以指定所有這些值,也可以使用“修訂號”和“內部版本號”的默認值,方法是按 
// 如下所示使用 '*': [assembly:AssemblyVersion("1.0.*")] 生成dll文件以后再點擊右鍵看看它的屬性,你就為在里面看到熟悉的內容了.

如果你使用.NET作為開發工具很長時間了,你肯定回會碰到“強名”(strong name)這個概念。這個概念並不意味你的組件命名方式必須類似於MyCompany.Gorilla.Biceps的方式。強名的力量體現在對組件的保護方面,.NET Framework使用強名來標識組件和保護組件使其免遭破壞。在這篇文章中我將說明如何建立強名,以及在.NET中使用強名的技巧。


1. 散列和簽名 為了了解強名的工作原理,你必須首先理解密碼學方面的兩個概念:散列(hashing)和數字簽名(digital signatures)。散列是用來為明文(plaintext)信息創建一個唯一的壓縮的值。這里的“信息”是一個很廣泛的概念,對於組件來說,信息就是它本身。如圖1所示,信息作為散列作為散列算法的輸入而被處理,對於強名情況,采用SHA1算法。 

散列是不可逆的,一旦計算出來,是不可能解密的。但是,散列在比較值方面是非常有用的。如果兩個組件生成同樣的散列值,你可以認為這兩個組件是相同的。相反,通過散列計算出來的值和以前計算的值不一樣,說明組件中某個地方被修改了。 因此通過散列值你就可以知道,組件是否被修改或破壞。然而你怎樣通過散列值來防止別人對你的組件的修改呢?下面就是我要講的“數字簽名”。 雖然數字簽名的具體數學原理很復雜,但是概念很簡單。一個數字簽名依賴於兩個相關的數字:公共秘匙(public key)和私有密匙(private key)。如圖2所示,當數據通過公共秘匙加密后,它只能通過私有密匙來解密,反之亦然。 

2. 組件的強名 在.NET中共同使用散列和數字簽名就能夠保護你的組件免遭破壞。其原理如圖3所示,首先從組件產生一個散列值,然后這個散列值通過你的私有密匙被加密,然后這個散列值和公共密匙被一起防止在組件中。 
在運行的時候,公共語言運行時(CLR)通過比較散列值驗證組件。首先公共的密匙用來解密散列,從當前的組件中計算出一個新的散列。如果它和原來的值吻合,那就通過了驗證
那么如果一個組件在簽名之后被破壞將會發生什么樣的情況呢?顯然,在運行時從組件中計算出來的散列值將不會與存儲在組件中通過私有密匙加密的散列值吻合,這樣公共語言運行時將拒絕加載該組件。 

注意強名只是保證了組件的完整性,而並非它的安全性,沒有什么辦法來防止某個人創建一個惡意的組件,並通過強名來給它簽名。你可以通過強名來驗證某個組件在簽名后是否被破壞。基於你對於信息的選擇。這一切將由你來決定是否相信從某個地方來的組件和代碼信息。 

3.強名的其它信息 

除了從組件內容求出來的散列,強名還包含一下三個方面的信息。 

l 組件簡單文本名稱 

l 組件版本號 

l 組件的語言文化代碼 

所有的這些信息,將為每個組件提供唯一的標識。有了這些信息,公共語言運行時可以決定一個組件是否被另一個組件通過引用的方式調用。當你從一個組件引用另一個組件,該組件將存儲被調用組件的公共密匙。在運行的時候,公共語言運行時將通過這些來判斷該組件是否來自正確的供應商。另外強名中的其它信息用來判斷組件是否符合引用的綁定策略(binding policy)的要求。 

4.使用強名的技巧 

.NET Framwork SDK和 Visual Studio.NET為指定強名提供了很多的工具,這是很有意義的,因為通過Visual Studio.NET來創建組件具有更多的選擇。在你簽名之前你必須創建一對密匙(公共密匙和私有密匙),通常密匙對放置在以.snk結尾的文件中。可以通過強名工具sn.exe來實現。 

sn -k MyKeyFile.snk 
如果你使用命令行編譯器(vbc.exe或者csc.exe),你就可以為組件連接器al.exe,指定密匙對。如下面的命令行所示,你可以將存儲在MyKeyFile.snk中的密匙對作為MyFile.dll的簽名。 

al /out:MyFile.dll MyFile.netmodule /keyfile:MyKeyFile.snk 
如果你使用Visual Studio .NET,你仍然可以通過命令行的方式產生你的密匙對。有了密匙對之后你就可以通過設定在組件信息文件(AssemblyInfo.vb 或者semblyInfo.cs)的【AssemblyKeyFile】屬性來把它包含到組件中。例如C#工程,你可以通過該屬性包含密匙文件而生成一個簽名組件。 

[assembly: AssemblyKeyFile("..\\..\\MyKeyFile.snk")] 

從被編譯的組件到密匙文件,【AssemblyKeyFile】屬性中的文件名必須包含完整的相對路徑。 

5.通過延遲簽名加密 

保護你的私有密匙是非常重要的,如果某個惡意的人取得了你的密匙,他生成的組件將和你簽過名的組件一樣。因此,應當把你的密匙設於高度的保密狀態,公司里面可能就只有幾個人知道。這樣以來,又怎么給你的組件簽名呢?如果就只有你一個人知道密匙,這樣會很繁瑣,因為你必須為公司中每個開發者開發出來的每個組件簽名。 

很幸運的是.NET為這個問題提供了一個很好的方法:延遲簽名。通過延遲簽名,你可以在只知道公共密匙的情況下創建和測試組件。只有在組件實際分發給用戶時才將私有密鑰匙包含到組件。下面是使用延遲簽名過程的一些技巧總結: 

1. 從公共/私有密鑰匙對中提取公共密匙。為了提取公共密匙,也就是存儲公共/私有密匙對,你可以使用強名工具,命令行如下: 

sn.exe -p MyKeyFile.snk MyPublicKeyFile.snk 

2. 將包含公共密匙的文件分發給公司所有的開發者,同時將包含公共/私有密鑰匙對的文件安全存放。 

3. 在組件信息文件中包含公共密匙的文件,並注明延遲簽名。 

[assembly: AssemblyDelaySign(true)] 
[assembly: AssemblyKeyFile("..\\..\\MyPublicKeyFile.snk")] 
如果你使用組件連接工具,而非Visual Studio .NET,你可以使用/delaysign命令行來表明延遲簽名。 

4. 如果你把組件保存在全局程序集緩存(GAC)中,應關閉對組件的驗證,因為GAC默認驗證每個組件的強名。如果組件沒有采用私有密鑰匙來簽名,這個驗證將會失敗。因此,出於開發和測試的目的你可以輸入如下的命名行: 

sn.exe -Vr MyFile.dll 

5. 這樣,你就可以在開發和測試的時候很自由的使用組件 

6. 當部署一個延遲簽名的組件的時候,你必須通過私有密匙來給它簽名。 

sn.exe -R MyFile.dll MyKeyFile.snk 

7. 最后,你必須通知GAC重新開啟對組件的驗證。命名行如下: 

sn.exe -Vu MyFile.dll 
6.可信任計算(TrsutWorthy Computing) 

你肯定聽說過微軟的“可信任計算”措施,它包含了有關微軟產品的很多安全方面的措施。微軟正慢慢的而且必然的朝着一個方向發展,那就是他們將使他們所有的軟件產品是默認安全的。如果你知道你在做什么,你就可以降低軟件(如Windows Server 2003)的安全級別。雖然降低了安全級別,但太可能使你受到突發事件的攻擊。 

當你給你的組件賦予強名,你在做就是“可信任計算”。通過強名來分發你的組件,會使得組件不太可能成為木馬和其他攻擊計算機黑客程序的載體。.NET Framework和Visual Studio .NET提供的工具保證了你分發組件的完整性。因此我強烈建議你使用這些工具,通過這些工具來使得計算世界變得更安全一點。 

 

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM