下面的內容要從新版Recruiting上線時出現的問題說起，
記得當時我們遵循以往發佈VS2003項目的方式將前臺頁面以及所有靜態文件，加上程序集DLL發佈到服務器上。
結果出現系統錯誤，大概意思是缺少***.cs文件。在開發和測試環境試過，也出現這種情況。
當我們將**.cs文件也更新上線時，系統就可以正常運行了。
所以當時的結論是VS2005的WEB項目發佈需要帶後臺文件，也沒有深究。
然而最近我又嘗試將**.cs文件拿走，訪問系統居然完全正常，無論怎麼重啓IIS都是正常的。同樣的操作隔段時間居然兩種不同的結果--------------奇怪！！~ 這點希望有高人指點。
其實網上大多數介紹的VS2005編譯方式有變化的文章指的是Web Site項目，而Web Application項目基本和VS2003一樣。（本人猜測文章撰寫的時候微軟的VS SP1還沒有出來吧）
所以本篇文章的結論是在VS2005種使用Web Application項目在編譯方式上和在VS2003中基本一致。
參考微軟的介紹:http://msdn2.microsoft.com/en-us/asp.net/aa336618.aspx
The Visual Studio 2005 Web Application Project model uses the same project, build and compilation semantics as the Visual Studio .NET 2003 web project model.
簡單介紹Web Site新的代碼編譯功能
而Web Site是默認在運行時動態編譯的，但都需要發佈源代碼，優點主要是允許運行時同時對 Web 窗體頁和 Codebehind 類進行動態編譯，無需再爲一次更改而重新編譯整個項目。
ASP.NET Web 窗體的優勢之一就是增加動態編譯後，您可以很輕鬆地更改 .aspx 頁，保存更改時頁面將動態更新，而不需要重新編譯（只要不使用代碼隱藏）。但動態編譯並不是
對每個應用程序都適合，而且第一次訪問某個應用程序時，動態編譯會導致初始性能降低。另外，可能很多時候您確實想要部署一個不含源代碼的應用程序。
如果您遇到上述情況，您會高興地瞭解到 ASP.NET Whidbey 具有支持預編譯 Web 站點的功能。ASP.NET Whidbey 支持兩種預編譯模式：就地預編譯和部署預編譯。
Web Application Projects和Web Site Projects的比較
下面是我從網上摘下來的兩種項目之間的比較，基本上Web Application項目可以說是微軟用來爲VS2003過渡的。
你該選擇哪種WEB編程模型
|
Option or Task
|
Web Application Projects
|
Web Site Projects
|
|
你有一個大型的Visual Studio .NET 2003 Web應用需要遷移到VS2005。
|
X
|
|
|
喜歡使用 single-page code 模型來開發網站頁面。而不是使用code-behind 模型來編寫網站頁面
|
|
X
|
|
喜歡採用下面的方式編寫網站：
在編寫頁面時候，爲了可以快速的看到編寫效果，動態編譯該頁面，馬上可以看到效果，不用編譯整個站點。 （就是說，只需要保存文件，然後在瀏覽器中刷新一下，就可以看到自己剛剛做的效果） |
|
X
|
|
需要控制編譯後應用程序集的名字
|
X
|
|
|
需要每個頁面產生一個應用程序集
|
|
X
|
|
WEB頁面或者WEB用戶控件中需要使用到單獨的類。
|
X
|
|
|
需要使用多個Project來構建一個Web應用。
|
X
|
|
|
需要處理pre-build 和 post-build 事件（編譯前後需要有自己額外的處理）
|
X
|
|
|
希望把一個目錄當作一個WEB應用來處理，而不需要新建一個Project 文件。
|
|
X
|
這兩種WEB編程模型的不同點：
|
Scenario
|
Web Application Project
|
Web Site Project
|
|
Project definition
|
跟 Visual Studio .NET 2003 類似，由於項目文件的存在，
只有被項目文件所引用的文件纔會在Solution Explorer中出現。而且只有這些文件纔會被編譯。 可以很容易的把一個ASP.NET應用拆分成多個Visual Studio項目。 可以很容易的從項目中和源代碼管理中排除一個文件。 |
一個目錄結構就是一個WEB項目。沒有項目文件存在。這個目錄下的所有文件，都被作爲項目的一部分而存在。
我們實際部署的一個網站，部署上當然不會有任何項目文件存在，如果你想對這個網站進行修改，用這種編程模型就非常適合。我們根本不用在乎這個WEB站點中，那些文件屬於哪個項目。
|
|
編譯和生成
|
跟Visual Studio .NET 2003的Web應用項目編譯模式幾乎一樣。
項目中的所有的code-behind 類文件和獨立類文件都被編譯成一個獨立應用程序集。這個應用程序集被放在Bin目錄下。因爲是一個獨立的應用程序集，你能夠指定應用程序集的名字、版本、輸出位置等信息。
例如：Model-View-Controller (MVC) 模式就可以在這裏很好的被使用。因爲它允許在WEB頁面和WEB用戶控件中引用一個獨立的類。
|
編譯（Build）命令僅僅是測試這個WEB站點是否編譯正確，調試一個WEB站點項目的時候，是通過依賴你的源代碼文件，ASP.net進行動態編譯頁面和類來實現的。
預編譯站點和動態編譯站點用的是同一個 compilation semantics ，你可以通過預編譯來提高站點的性能。
ASP.net 動態編譯系統提供了兩種模型：默認的batch 編譯模型和fixed-names 編譯模型。 batch 編譯模型中，被編譯成多個應用程序集（典型的是每一個目錄被編譯成一個）。這時候你看應用程序集，很難對應上是哪個目錄。 fixed-names 編譯模型中，網站的每個頁面或者每個用戶控件被編譯成一個應用程序集。 |
|
Iterative development
|
調試或者運行Web頁面的時候，你必須全部編譯整個WEB項目。
編譯整個WEB項目通常比較快，因爲Visual Studio使用了增量編譯模式，僅僅只有文件被修改後，這部分纔會被增量編譯進去。 |
你可以配置Visual Studio 2005的編譯屬性：編譯整個站點、編譯一個指定頁面、或者什麼都不作。在最後一種情況下，當你運行一個WEB站點的時候，Visual Studio 僅打開一個瀏覽器，並訪問當前或者起始頁，當這個請求被髮送後，ASP.net 纔開始動態編譯。
這種模式下，頁面被動態編譯或者被編譯成不同應用程序集，所以如果你調試或者運行一個頁面的時候，不需要整個項目被編譯通過。有錯誤的部分跟你使用的部分可以互不干擾。
默認情況下，當你運行或調試任何WEB頁的時候，Visual Studio完全編譯Web Site項目。 這麼做可以看到編譯時的所有錯誤。但是，在開發進程中，完全編譯整個站點會是相當慢的。所以推薦你在開發調試中，只編譯當前頁。 |
|
部署
|
因爲所有的類文件被編譯成一個應用程序集，當你部署的時候，只需要把這個應用程序集和 .aspx文件、.ascx文件以及其它靜態內容文件一起部署。
這種模型下，.aspx 文件將不被編譯，當瀏覽器訪問這個頁面的時候，纔會被動態編譯。
不過，如果你使用Web Deployment Projects (一個Visual Studio 2005的插件，沒有被默認包含到VS2005中),你就可以把 .aspx 文件也編譯進入一個應用程序集中。 （大家提到的可以將前臺頁面編譯到DLL的方法，其實還有另外一種方法，詳可參考：http://aminic.blog.hexun.com/554026_d.html）
如果你只修改了小小的一行代碼，你也需要把整個項目的所有代碼都編譯，並且發佈包含所有代碼的這個應用程序集。 |
使用Visual Studio 的 Publish Website 命令，你可以把.aspx 文件 和 code-behind 文件編譯成應用程序集，所以你看到的編譯後的 .aspx 文件頭髮生了變化。（注意：Build 命令並不會給你可部署的應用程序集）
最新版本的 Publish 將支持僅編譯 code-behind 文件，這樣部署的時候，將不改變 .aspx 文件。 默認是在Bin目錄下預編譯成幾個應用程序集，典型的是一個目錄對應一個應用程序集。
fixed-names 部署選項可以讓每一個WEB頁面或者每個WEB用戶控件創建一個應用程序集，這樣每個頁面都有一個可部署的應用程序集。但是，fixed-names 部署選項會增多應用程序集的個數，而且實際內存使用也會增大。 |
|
從Visual Studio .NET 2003升級
|
因爲跟VS2003採用了一樣的WEB項目開發模型，升級是非常非常簡單的。
|
Web site 項目的編譯選項不同導致了它跟Visual Studio .NET 2003WEB項目的極大不同。
雖然微軟提供了一個轉換向導，但是如果你的項目如果是一個複雜的VS2003項目，使用這個轉換向導後，你還需要對照轉換手冊，做很多工作。 如果你要從VS2003升級，建議不要用這種WEB站點開發模版。而是使用Web application 項目。 |
codebehind和src的區別
以前開發項目的時候經常搞不清楚codebehind和src的區別，下面是我從網上摘下來的，供參考：
在 ASP.NET 中使用代碼隱藏方法來設計Web 窗體，可使頁代碼能夠更清晰地從 HTML 內容中分離到完全單獨的文件中。
通常一個 @page 指令如下：
<%@ Page language="c#" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false" Inherits="WebApplication1.WebForm1" %>
其中有三個屬性（Inherits、Src、CodeBehind）非常容易混淆，下面分別給予說明。
Inherits
Inherits 屬性用於定義當前 Web 窗體所繼承的代碼隱藏類(該類是 System.Web.UI.Page 的派生類)。
這個 inherits 屬性只用於採用代碼隱藏方式編寫的 Web 窗體，也就是，如果你的代碼全都是在 Web 窗體的
<script runat="server"></script> 標籤中，就不必用這個屬性了。
Src
Src 屬性用於指定“代碼（隱藏）文件”在文件系統中的位置，以便於 ASP.NET Framework 用 Just-In-Time (JIT)
編譯器動態編譯 Web 窗體時能夠找到它。用 Inherits 指明的類，就是放在這個類代碼（隱藏）文件中。
通常 ASP.NET Framework 使用這些類時，首先會到已編譯的程序集中查找，
如果找不到就會把在 Src 屬性中提供的代碼文件重新編譯，所以 Src 屬性和 Inherits 屬性並不互斥。
需要說明的是，Visual Studio .NET 並不使用 Src 屬性，
這就意味着 Visual Studio .NET 總是指望你用“生成”菜單中的生成操作來產生已編譯的程序集
（通常是編譯成DLL放在/bin目錄中，這樣一來，在發佈應用系統時，就可以不用發佈源代碼了），
而以後不會發生需要動態編譯的情況。所以如果你是在 Visual Studio .NET IDE 中開發的話，
要時常注意用“重新生成”功能來編譯發生變動的類，否則，將會發生諸如找不到類呀什麼的一系列問題。
Codebehind
呵呵，Codebehind 屬性並不是一個真正的 ASP.NET 屬性，在ASP.NET 文檔中是找不到它的。
它其實只是一個 Visual Studio .NET 屬性，
Visual Studio .NET 就是借用這個屬性來很好地跟蹤管理項目中的 Web 窗體和與之相對的代碼隱藏文件，
比如當你在設計環境中往 Web 窗體上放入一個服務器控件時，
Visual Studio .NET 將自動找到與該 Web 窗體相對應的代碼隱藏文件，並自動插入相關的代碼。
因此，用 Visual Studio .NET 作開發時，不可輕率地將 Codebehind 屬性換成 Src 屬性，他們的功能作用不同。
