轉眼間，距離微軟推出.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