由于我們的項目底層使用到一個通過LogicalCallContext實現的上下文數據管理框架，導致所有的Unit Test不能正常運行。具體的現象在《只在UnitTest和WebHost中的出現的關于LogicalCallContext的嚴重問題》有過詳細的介紹。解決的方案就是對相關的程序集進行強簽名，并加到GAC中，是Unit Test能夠識別基于　　　　LogicalCallContext項目的類型。有了Visual Studio這個強大的IDE，程序集的簽名工作很好實現——僅僅需要在Project的Properties對象框的Signing Tab中指定一個Key File就可以了。但是，Visual Studio做得不夠好。

　　一、Visual Studio會自作主張地在項目根目錄下復制一個Key File 

　　舉個例子，假設一個解決方案中具有兩個項目：Lib1和Lib2。現在我們需要使用“同一個Key File”對Lib1和Lib2進行簽名，Lib1、Lib2和Key File（Key.snk） 對應的目錄結構如右圖所示：Key.snk和Lib1和Lib2處在相同的目錄下面。

　　現在我們右擊Lib1項目文件，選擇Properties菜單項進行項目屬性對話框，選擇Signing Tab頁進行程序集簽名相關設置。選中Sign the assembly復選框，在下拉框中選擇<Browse>選項，并在彈出的文件選擇對話框中我們的Key File：Key.snk。

　　但是當你選中Key.snk這個文件的時候，Visual Studio并不會用將這個文件作為對本程序集進行簽名的Key File，而是會自作主張地將該文件拷貝到Lib1所在的根目錄下。最終被用于程序集簽名的不是我們希望的那個File Key，而是該File Key的復制品（如下圖所示）。

　　我不太明白微軟如此設計具有怎樣的考慮，但是對于我們目前的項目來說，我是無法接受的。上面的例子中只有兩個需要簽名的項目，就需要維護兩個Key File，但是我們的項目中有數十個項目，就意味著需要維護數十個不同的Key File，從維護的角度講，如果有朝一日我需要更換另一個Key File， 我就需要為每個項目進行更新。

　　那么我們有沒有辦法讓所有項目采用同一個Key File進行簽名呢？當然有，不然我也不會寫這篇文章了。總的來說，我們三種不同的解決方案。

解決方案1：通過AssemblyKeyFileAttribute特性指定Key File

　　AssemblyKeyFileAttribute特性定義在System.Reflection命名空間下，專門用于指定在對項目進行強簽名時采用的Key File。所以我們只需要在AssemblyInfo.cs中（也可以在其它地方）指定我們采用的Key File文件路徑即可。通過下面的代碼，我們指定我們對Lib1項目指定了我真正期望用于進行簽名的那個Key File。

   1: [assembly: AssemblyVersion("1.0.0.0")]

   2: [assembly: AssemblyFileVersion("1.0.0.0")]

   3: [assembly: AssemblyKeyFile("..//Key.snk")]

NET技術：Visual Studio對程序集簽名時一個很不好用的地方，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。