移動項目開發筆記(一個使用者控制項引起對asp.net 2.0編譯的思考)

一、起因:    
     Team Dev的一名開發人員突然離職，他把他負責的模組任務交給了我。其中一個模組是他寫了一個使用者控制項，我在我的頁面尚始終都用不起，運行時發生錯誤，錯誤訊息是：The base class includes the field *****, but its type (****) is not compatible with the type of control (ASP.webusercontrol_ascx).
 二、經過:
    遇到這個問題後個人感覺那個使用者控制項在頁面上註冊沒有成功。尋找了頁面註冊代碼：

<%@ Register Src="ProjectInfo.ascx" TagName="ProjectInfo" TagPrefix="uc3" %>
<uc3:ProjectInfo ID="ProjectInfo1" runat="server" />

通過反覆的尋找都發現這個代碼沒有問題，我也尋找以前的使用者控制項頁是這樣註冊的。那到底是那兒出了問題了呢?功夫不負有心人，終於找到問題所在了，使用者控制項的申明是這樣寫的

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="ProjectInfo.ascx.cs" Inherits="ProjectInfo" %>

問題就在那CodeFile，由於所在的項目是Web Application應用程式，申明的使用者控制項應該是CodeBehind，怎麼回變成CodeFile呢？終於找到問題所在了。當我把CodeFile修改成CodeBehind後頁面就能正常顯示了。那這兒被誰誰修改成CodeBehind了。通過查看VSTS修改曆史，沒有人對這個檔案進行修改，當時增加這個檔案的時候就已經是CodeFile了。Web Application預設增加的使用者控制項都是CodeBehind的。除非不是Web Application，當時我就建立的一個web site網站，就添加了一個使用者控制項，一看果然是這樣什麼的:

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="ProjectInfo.ascx.cs" Inherits="ProjectInfo" %>

 問題的來源頁找到了，原來這個使用者控制項是通過Web Site網站添加的移植過來的而引起的。謝謝上帝，終於把這個問題解決了。
三、思考
問題找到了。問題的來源頁找到了。那麼為什麼這裡用CodeFile就不行了。這個才是問題實質。為什麼Web Application申明的控制項或者頁面都是用CodeBehind而不是用CodeFile來申明？
四、 結果

通過不斷的尋找原因，終於把Web Application用CodeBehind而Web Site用CodeFile找到了?
原來Web Application和Web Site的編譯機制是不同的。
Web Site：當我們使用VS.net建立一個頁面的時候，VS會自動的建立一個CodeBehind檔案，但是當我們編譯網站的時候，VS.net會自動的根據分頁檔的內容，產生一個臨時的”Partial”類，然後把這個partial類和CodeBehind中的partial類整合編譯，最後產生一個位於bin中的dll檔案。（CodeFile來實現）
Web Application:當我們在頁面上加入一個新的控制項時候，VS.net自動會在 CodeBehind代碼中增加一個Protected對象的申明（Partial類），並在代碼中使用和操作這個對象，VS.net會時刻維護分頁檔的控制項與 （Partial類代碼檔案的申明）之間同步。當我們編譯網站時，VS.net將所以CodeBehind檔案編譯在一起，產生一個位於bin目錄中的dll檔案。（CodeBehind來實現）

通過上面的比較後，我們現在已經是比較明白上面的使用者控制項申明應該用CodeBehind而不能用CodeFile。其根本原因就是：Web Application的頁面用的是CodeBehind的方式，如果裡面的使用者控制項又用CodeFile的方式來編譯的化，就出現矛盾，那麼頁面就優先於使用者控制項的方式，直接把所有的代碼檔案編譯成dll檔案就可，而不是把分頁檔產生一個partial類再和代碼檔案一起編譯。因此那樣的話頁面的使用者控制項將不會被VS.net根據頁面的內容產生一個臨時類和CodeBehind中的Partial類整合編譯，缺少對使用者控制項的申明，從而會出現：The base class includes the field *****, but its type (****) is not compatible with the type of control (ASP.webusercontrol_ascx).

其他參考資料: http://blog.csdn.net/ups216/archive/2006/09/06/1186835.aspx