Microsoft代碼分析鼓勵我強調所有程序集的名稱。但根據微軟I have to manually disable the "Bypass Feature" that they are checked。當我必須手動打開旁路功能時,爲什麼我應該使用強名稱程序集?
如此以來,.NET Framework 3.5版Service Pack 1個的強名稱不驗證。
爲什麼我還要用強名稱簽署我的程序集?
謝謝! Stefan
Microsoft代碼分析鼓勵我強調所有程序集的名稱。但根據微軟I have to manually disable the "Bypass Feature" that they are checked。當我必須手動打開旁路功能時,爲什麼我應該使用強名稱程序集?
如此以來,.NET Framework 3.5版Service Pack 1個的強名稱不驗證。
爲什麼我還要用強名稱簽署我的程序集?
謝謝! Stefan
如此以來,.NET Framework 3.5版Service Pack 1個的強名稱不驗證
好,爲掩蓋說法,是不是真的。部分事實是,如果應用程序在完全信任和中運行,它們不再驗證,程序集存儲在可信位置。本地機器或Intranet區域。
在構建時,你有沒有可靠的任何想法,其中組件最終將被保存。你可能有一個部署計劃,但這樣的計劃往往會在方便或必要時被否決。這包括在需要將程序集存儲在GAC中時需要強名稱。一個解決DLL地獄問題的方法或許,可能需要從現在起完成年。
漂亮該死的不方便的,如溶液不可用,因爲你沒有強命名大會。而且到那時幾乎總是爲時太晚,因爲它需要重建一切。強名稱是簡單的,很少有很好的理由可以跳過它。或者,如果你不同意它,只是壓制消息,代碼分析規則確實符合「你有沒有考慮過這個問題?」警告類別。溫和地提醒不明確的細節。
如果惡意更改(或其他格式不正確)的可執行代碼的可能性與您無關,使用強名稱的另外兩個原因是(1)版本控制(例如DLL地獄問題)和( 2)命名保護(即無關的代碼,它的組裝和你的名字一致)。
另外,你提到的旁路功能是性能的黑客,爲了在假設利用(希望總是安全地)跳過完整性檢查(惡意的或畸形的代碼探測)步驟。
值不值寫着:http://msdn.microsoft.com/en-us/magazine/cc163583.aspx和http://www.codeproject.com/Articles/8874/Strong-Names-Explained