紀念花了我一個半小時的茶包。

某個古蹟 ASP.NET Web Site 專案,使用 IIS 測試 OK,在 VS2022 按 F5 Debug 時卻編譯不過,噴出 Build (web): 並未將物件參考設定為物件的執行個體。/Object reference not set to an instance of an object錯誤:

爬文查到有人說是 Oracle.DataAccess 版本匹配問題,試著移除 ODP.NET 相關程式錯誤會消失,證實兇手是 ODP.NET 無誤。喵的! 我又掉進 ODP.NET 版本地獄了~~~

反覆檢查 ODP.NET 版號及繫結導向設定都沒錯,甚至裝了發行者原則檔試手氣,我憑著多年 ODP.NET 版本偵錯經驗使出渾身解數,錯誤依舊。得到的結論是:一模一樣的程式在 IIS 可正常運行,但 Visual Studio 2022 就是不認得我的 Oracle.DataAccess 2.122.2 版。

在 ASPX 加上 typeof(Oracle.DataAccess.Client.OracleConnection).Assembly.CodeBase 跑 IIS 得到 file:///C:/WINDOWS/assembly/GAC_32/Oracle.DataAccess/2.122.1.0__89b483f429c47342/Oracle.DataAccess.dll ,對照 Process Monitor 側錄記錄,我好像懂了什麼:

VS2022 的 Microsoft.VisaulStudio.Web.Host.exe 查了 C:\Windows\Assembly 的 GAC_64、GAC_MSIL、GAC 目錄,但沒查 IIS 測試得到的 GAC_32,該不會是因為 VS2022 改 64 位元造成的?

查了 MSBuild,果然是 64 位元版。

上回有解決過 MVC 專案設定 IISExpress 32/64 問題,但 MVC 為先編譯完再丟給 IISExpress 執行,與 Web Site Project 的即時動態編譯模式大不相同,Web Site Project 這等史前遺跡,我對 VS2022 的支援性沒報什麼期望。

朕乏了,改用 VS2019 順利編譯、除錯,修好專案 Bug 收工,完全不想用 VS2022 跟 Web Site Project 奮鬥。

【小結】

  1. 若專案有用到 ODP.NET,早日升級 .NET 4/Managed ODP.NET 可降低痛苦指數,遠離 ODP.NET 版本地獄。
  2. 如果 Web Site Project 使用 .NET 2.0/3.5 + Unmanaged ODP.NET 前題無法改變,用 VS2019 維護偵錯會比較愉快。

VS2022 is 64bit now and it casues issues when running web site project need 32bit unmanaged ODP.NET.


Comments

Be the first to post a comment

Post a comment


37 - 11 =