我想強調一個託管應用程序,它通過interop引用許多託管程序集以及ActiveX和COM組件(用C++編寫)。而且因爲強命名的程序集不能引用命名較弱的程序集,請告訴我應該準備哪些問題以及遇到什麼問題,特別是在處理那些ActiveX和COM interops時?當強名稱簽署託管應用程序時需要考慮什麼?
這個應用程序的解決方案很大。它由50多個託管C#,Vb.net,本機C++和託管C++/CLI組成。因此,您提供的信息越多,真實生活中的故事越多,我可以更好地準備並避免頭痛。
謝謝。
我想強調一個託管應用程序,它通過interop引用許多託管程序集以及ActiveX和COM組件(用C++編寫)。而且因爲強命名的程序集不能引用命名較弱的程序集,請告訴我應該準備哪些問題以及遇到什麼問題,特別是在處理那些ActiveX和COM interops時?當強名稱簽署託管應用程序時需要考慮什麼?
這個應用程序的解決方案很大。它由50多個託管C#,Vb.net,本機C++和託管C++/CLI組成。因此,您提供的信息越多,真實生活中的故事越多,我可以更好地準備並避免頭痛。
謝謝。
確實沒有什麼問題,除了可靠地存儲.snk文件。
請記住,每個將使用您的程序集的第三方程序集都將擁有您的依賴關係中提及的assmeblies的密鑰,每次它將加載您的程序集時,它將檢查加載的程序集是否仍然使用該密鑰簽名。這樣做是爲了防止通過一些惡意代碼錯誤地裝配你的程序集。
這意味着,除非您可靠地存儲用於簽署程序集高級版本的.snk文件,否則不會強制用戶重新添加引用來發布新版本。因此,存儲.snk文件並對任何給定程序集的每個版本使用相同的文件。無論你爲不同的程序集使用不同的.snk文件,還是爲所有程序使用不同的文件,因此每個公司的.snk文件就足夠了。
有關上述詳細信息,請參閱this question和this perfect answer。
到目前爲止,我還沒有遇到與強名稱相關的任何問題(也使用COM interop程序集)。如果您獲得的第三方組合沒有強名稱,您可以自己進行後期簽名,這樣可以使所有組件都具有強大的名稱。
當然,使強命名的interop程序集不能保護要修改或替換的底層COM DLL,因此強名稱的「保護」並不真正將其本身擴展到COM組件,即使互操作程序集強烈命名。
這就是我想強調應用程序命名的原因。但是,我想知道應用程序的體系結構以及我們的VS解決方案的結構的複雜性。謝謝。 – tranmq