眼看 Web Site Project 都快入土為安了,沒想到今天還能學到新知。(換言之,這篇文章的知識比北極還冷,非古蹟維護小組成員請迴避)

同事使用 wdproj 預先編譯 WSP 專案,部署到伺服器換版後,某支即時編譯的 ashx (C# 寫在 .ashx 裡) 冒出找不到 Namespace 錯誤,追查發現,該 Namespace 來自 App_Code 下某支共用函式 .cs,而本次有更新 App_Code.dll。 反組譯確認 App_Code.dll 的確包含所需的 Namespace 及型別,但換回舊版 App_Code.dll 即告恢復正常,又證實了問題出在今天更新的 App_Code.dll。 而另一件詭異的事是使用 App_Code.dll 該型別還有其他 WebForm,卻又可以正常執行。

歷經一陣摸索,我靈光一現想起預先編譯時除了 App_Code.dll,還會有個 App_Code.compiled,它是個文字檔,這麼多年來第一次打開它看內容:

<?xml version="1.0" encoding="utf-8"?>
<preserve resultType="6" virtualPath="/MyWebApp/App_Code/" hash="ffffffffe2cc33ba" 
  filehash="" flags="140000" assembly="App_Code" />

裡面有個 hash 值,代表可能每次編譯的值都不同,所以 App_Code.dll 與 App_Code.compiled 是成對的,沒同步更新會導致動態編譯對應不到類別。 詢問同事,這次部署只有更新 App_Code.dll,沒換 App_Code.compiled。叮咚叮咚! 連同 App_Code.compiled 一併更新,故障就消失了。 .compiled 與動態編譯有關,這就可以解釋其他用到 App_Code 程式的 WebForm .aspx 之所以沒出錯,是因為它們使用預先編譯好的 FolerName.dll,躲掉動態編譯機制失常的影響。

由此學到一事, App_Code.compiled 要隨 App_Code.dll 一起部署才不會出問題。

A case of web site project failure when updating App_Code.dll without App_Code.compiled.


Comments

Be the first to post a comment

Post a comment


9 + 8 =