今天解決掉一件糾纏近十年的困擾,敲開薰!

過去我分享過不少組件重新導向的技巧,其實十之八九都是 ODP.NET 引起的(為此我還曾研發過暴力解法暴力解法懶人工具核武級 ODP.NET 版號暴力破解工具,看我怨念有多深),版號衝突問題大多可藉由在 config 加入 bindingRedirect 設定排除,只有一種例外 -
組件繫結重新導向鬼問題-版號高低之謎

它會發生在元件參照 ODP.NET 版號比網站高的狀況。例如有個 ASP.NET Web 參照了一顆 DataProvider.dll,DataProvider.dll 參照 ODP.NET 2.121.2,而 ASP.NET Web 本身也用到 ODP.NET,參照的版本是 2.112.1,編譯時便會噴出以下錯誤,即便加上 bindingRedirect 導向也無解:

大家或許會想,那叫 ASP.NET 也升級 2.121.2 不就好了?為了某顆小元件的一個小功能,被逼著升級整個網站用的 ODP.NET 版本,專案換顆 DLL 重新編譯事小,得重新驗證測試相容性事大,不符實務做法。總之,是件麻煩事。

今天再遇到類似狀況,但我觀察到一個現象。同一個專案在同事 A 的機器上可正常編譯,在同事 B 跟我的機器上就會發生元件參照 ODP.NET 版號高於網站參照 ODP.NET 版號的錯誤,引起我的好奇。同事 A 的 Windows 環境肯定有什麼特別之處,可以克服這個問題。經過一陣推敲,我想到一個嫌犯 - ODP.NET 發行者原則檔,比對發現同事 A 有安裝發行者原則,而同事 B 與我沒有!

此一發現令我士氣大振。找到我的 2.121.2 ODP.NET 安裝目錄:

用 gacutil /i Policy2.112.Oracle.DataAccess.dll 安裝發行者原則:

檢查 C:\Windows\assembly\GAC_32 看到 Policy.2.112.Oracle.DataAccess,代表 2.112 版將會導向 2.121.2 版:

神奇的事情發生,裝完發行者原則,我的版本過高編譯錯誤消失了!

由此學到新知識,發行者原則比 config bindingRedirect 效果強大,足以克服元件參照版本高於網站本身參照版本版號的困境,未來遇類似問題,除了換版升級外,多了一個輕巧便捷的好選擇。


Comments

# by Huang

我的sop供參考:先解GAC、解元件服務、反向安裝回來(註冊元件服務,加GAC),省掉很多麻煩。cpu目標平台不一致是可能的異常。

Post a comment