從編譯 DotNetOpenAuth 學到的強名稱簽章知識總結

編譯 DotNetOpenAuth 5.1 源碼遭遇強名稱驗證失敗，完整記錄 `sn.exe` 金鑰生成、`msbuild` 強簽編譯、GAC 註冊失敗排查、延遲簽章陷阱的完整過程。

背景

• DotNetOpenAuth 5.1 使用 .NET 4.5 `async/await`，NuGet 僅有 4.3 版
• 源碼編譯產出 20 個 DLL，官方提供 `tools/drop.proj` 使用 `ILMerge` 合併

第一次編譯 (無強簽)

msbuild tools/drop.proj

輸出 `drops\v4.5\Debug\DotNetOpenAuth.dll` (已合併)

引用測試 → 強名稱驗證失敗

Could not load file or assembly 'DotNetOpenAuth' or one of its dependencies. 
Strong name signature could not be verified. The assembly may have been tampered with, 
or it was delay signed but not fully signed with the correct private key. 
(Exception from HRESULT: 0x80131045)

強名稱簽章流程

1. 生成金鑰對 (sn.exe)

sn -k mykeyfile.pfx          # 生成公開/私鑰對到 .pfx
sn -i mykeyfile.pfx mycontainer # 安裝至強名稱金鑰容器
sn -p mykeyfile.pfx mykeyfile.pub # 導出公開金鑰
sn -q -t mykeyfile.pub       # 顯示公開金鑰 Token

2. 使用公開金鑰進行 msbuild 強簽編譯

msbuild /p:KeyPairContainer=mycontainer,PublicKeyFile="C:\Full\Path\mykeyfile.pub" tools/drop.proj

3. 測試 → 同樣失敗！

**頓悟**：強名稱驗證**僅在組件安裝至 GAC 或啟用強名稱驗證時生效**。專案參考本地 DLL 不觸發驗證，除非專案設定 `SignAssembly=true` 並要求強名稱。

嘗試安裝至 GAC

gacutil /i DotNetOpenAuth.dll

報錯：`Failure adding assembly to the cache: Strong name signature could not be verified. Was the assembly built delay-signed?`

延遲簽章陷阱分析

• `ILMerge` 合併多個已強簽組件時，**預設不重新簽章**，導致合併後組件簽章無效
• `drop.proj` 中 `ILMerge` 命令缺少 `/keyfile` 或 `/keycontainer` 參數
• 需在 `ILMerge` 步驟明確指定私鑰重新簽章，或合併前不強簽、合併後再統一強簽

正確流程建議

1. 源碼專案**不設定** `SignAssembly` / `AssemblyKeyFile`
2. 編譯產出無簽章 DLL
3. `ILMerge` 合併時加入 `/keycontainer:mycontainer` 參數，直接產出強簽合併組件
4. 或：合併後對單一 DLL 執行 `sn -R assembly.dll mycontainer` 重新簽章

關鍵知識點總結

強名稱 ≠ 安全性。它解決**組件身分唯一性**與**版本衝突**，不防範惡意竄改 (需 Authenticode 代碼簽章)。現代 .NET Core/.NET 5+ 已淡化強名稱，改用套件管理 (NuGet) 解決版本問題。