轉眼間，距離微軟推出.net平台已經4年了，.net也經歷了 從 1.0 到 1.1 再到2.0的升級。 由於 ASP.net 2.0 和vs 2005 IDE的各種優越特性的吸引，大伙都忙著學習2.0，將項目升級至vs 2005 下面開發。 但實際上，很多項目由於種種原因，無法升級到新版本。隨著時間的變遷，老版本的項目維護問題越來越讓人頭痛。雖然.Net誕生時間不長，但4年的時間足夠積累一量的項目。
我手上就有個用vs.net 2002開發的項目，由於種種原因一直沒有升級（主要是因為該項目在vs.net 2003出來之前已經良好運行了一段時間，並且服務器上的其他ASP.net程序無法適應.Net 1.1的安全性要求。）
當初公司開發平台升級時，在電腦上同時安裝vs.net 2002 和vs.net 2003, 暫時性的解決了不同版本的項目的維護。再後來，項目過了維護期了，很久沒更新了，我電腦也重裝了，vs.Net 2002就徹底掃地出門了。可到了2005年，客戶每隔1，2個月就提出修改要求，而且要快，沒辦法 ，客戶太牛B，過了維護期也要改。可問題來了，沒有vs 2002，無法編譯啊。
在電腦上裝個.Net framework 1.0, 使用手工方式調用 csc 編譯修改後的代碼，非常麻煩，項目有一堆引用，編寫命令行很繁。特別是項目有很多文件夾時更痛苦。也考濾過寫個程序編譯，但我懶，一直沒實現。
今天又碰上要修改程序，突然想起很早的時候（2002年）使用過一次 @Page指令的 Src 屬性，使用此屬性，asp.net將采用自己的編譯模型而不是使用vs.net IDE的CodeBehind方式，代碼無需編譯成dll 便可發布，訪問站點時，asp,net會自動將aspx文件 和 .ASPx.vb 文件一起編譯。 這種方式的缺點主要有兩個：1、 代碼文件(.vb) 必須發布到服務器上, 2、vs.net IDE 不支持。 因為第二個問題的原因，後來放棄使用了，這事也就忘了。 現在正愁沒辦法編譯程序呢，只要能讓修改的代碼生效，其他的缺點都不考濾了。 反正所有的源代碼都發布到服務器上了。 我在@Page 指令中 加了個 Src屬性，使用的值與CodeBehind 屬性的值相同，指向代碼文件。再將.vb 文件中的代碼修改完畢。刷新，修改生效，維護完成。爽啊。以後就這麼干了。由於vs.net IDE 不支持，MSDN上也是一筆帶過，未必有很多人知道.Net具有這種編譯模型。現在將其共享出來，如果有人也正經受我一樣的痛苦，您也可以考濾在頁面中添加Src，呵呵，簡單快捷，改完代碼就生效，不用再絞盡腦汁找工具編譯了。
總結： 包括我在內的許多人，都更喜歡將程序編譯成dll,感覺這才更像一個發布的軟件。其實，采用“將所有源代碼發布到服務器，運行時完整的編譯代碼”的方式非常不錯，大大簡化日後的維護工作。很多公司為客戶作的項目其實沒必要對客戶隱藏源代碼。在這種情況下，使用這種方式為以後的維護工作帶來巨大的好處，無論.Net 升級了n次，不管你電腦上是否裝有相應版本的開發工具，你都無需擔心，用記事本都可以搞定一切。
注意： 所有版本的 ASP.net都支持此編譯模式，但vs.Net 2002和2003的 IDE不支持，無法打開設計視圖。 剛出來的vs 2005 IDE支持這種編譯模式。 使用Src 屬性時，CodeBehind屬性不再需要了，但建議你仍然保留，如果你突然需要回到計視圖，它還可以幫你的忙。 Inherits 屬性也不需要，但強烈建議你不要刪除它，因為如果你在ASPx文件的控件聲明中直接綁定了事件（如： OnClick="....") ，沒有Inherits屬性會報錯。
出處：cwbboy BLOG
