Asp.Net2.0編譯模式

Asp.Net2.0的編譯模式和1.1相比改變了好多

ASP.NET 2.0 為 Web 應用程式提供三種不同的編譯模型：

•	普通 (ASP.NET 1.x) — 在一個普通的 ASP.NET Web 應用程式中，程式碼後置檔案被編譯到一個程式集並儲存在 /bin 目錄中。根據要求編譯 Web 頁 (ASPX)。該模型對大多數 Web 網站都運行得不錯。但是，編譯過程使得第一次請求 ASP.NET 頁時的速度比隨後的請求速度緩慢。ASP.NET 2.0 繼續支援這種編譯模型。
•	部署先行編譯 — ASP.NET 2.0 的一種新功能，允許在部署前對項目進行完整編譯。在完整編譯中，所有的程式碼後置檔案、ASPX 頁面、HTML、圖形資源以及其他的後端代碼都被編譯到一個或多個可執行程式集中，這取決於應用程式的大小和編譯設定。這些程式集包含所有的已編譯 Web 站台碼，而資源檔和設定檔被複製，沒有做修改。這種編譯方法以犧牲修改部署後 Web 網站的能力為代價，提供了最好的效能和安全性。如果您使用高可見或高安全的 Web 網站，這種選項是最終部署的最好選擇。但是，如果您正在構建一個運行局部 Intranet 的小網站，並且更改網站非常頻繁，那麼完整先行編譯可能有點過分。
•	ASP.NET 2.0 編譯模型也允許先行編譯應用程式的所有程式碼後置檔案並且仍可以更新代碼。可以將程式碼後置檔案和原始的 .ASPX 檔案（都是局部類）編譯到一個先行編譯類中（頁面的基類）。如果選擇在運行時編輯 .ASPX 檔案，只需重新編譯頁面即可。
•	完整的運行時編譯 — 在部署先行編譯的另一個極端，ASP.NET 2.0 提供一種在運行時編譯整個應用程式的新機制。也就是說，可以將未編譯的程式碼後置檔案和其他相關的代碼放在 \app_code 目錄中，並讓 ASP.NET 2.0 建立並維護對程式集的引用，這些引用將在運行時根據這些檔案產生。這種選項以在伺服器上儲存未編譯代 ASP.NET 2.0 為 Web 應用程式提供三種不同的編譯模型： • 普通 (ASP.NET 1.x) — 在一個普通的 ASP.NET Web 應用程式中，程式碼後置檔案被編譯到一個程式集並儲存在 /bin 目錄中。根據要求編譯 Web 頁 (ASPX)。該模型對大多數 Web 網站都運行得不錯。但是，編譯過程使得第一次請求 ASP.NET 頁時的速度比隨後的請求速度緩慢。ASP.NET 2.0 繼續支援這種編譯模型。 • 部署先行編譯 — ASP.NET 2.0 的一種新功能，允許在部署前對項目進行完整編譯。在完整編譯中，所有的程式碼後置檔案、ASPX 頁面、HTML、圖形資源以及其他的後端代碼都被編譯到一個或多個可執行程式集中，這取決於應用程式的大小和編譯設定。這些程式集包含所有的已編譯 Web 站台碼，而資源檔和設定檔被複製，沒有做修改。這種編譯方法以犧牲修改部署後 Web 網站的能力為代價，提供了最好的效能和安全性。如果您使用高可見或高安全的 Web 網站，這種選項是最終部署的最好選擇。但是，如果您正在構建一個運行局部 Intranet 的小網站，並且更改網站非常頻繁，那麼完整先行編譯可能有點過分。 • ASP.NET 2.0 編譯模型也允許先行編譯應用程式的所有程式碼後置檔案並且仍可以更新代碼。可以將程式碼後置檔案和原始的 .ASPX 檔案（都是局部類）編譯到一個先行編譯類中（頁面的基類）。如果選擇在運行時編輯 .ASPX 檔案，只需重新編譯頁面即可。 • 完整的運行時編譯 — 在部署先行編譯的另一個極端，ASP.NET 2.0 提供一種在運行時編譯整個應用程式的新機制。也就是說，可以將未編譯的程式碼後置檔案和其他相關的代碼放在 \app_code 目錄中，並讓 ASP.NET 2.0 建立並維護對程式集的引用，這些引用將在運行時根據這些檔案產生。這種選項以在伺服器上儲存未編譯代碼為代價，在更改 Web 網站內容方面提供了最大的靈活性。 選擇最佳的編譯選項要由具體的情況和需要決定，但編譯模型要有靈活性。即使選擇使用 \app_code 目錄來儲存程式碼後置檔案，您仍可以使用完整的編譯方法來部署應用程式。 碼為代價，在更改 Web 網站內容方面提供了最大的靈活性。 批編譯 在 ASP.NET 2.0 中，可以利用單個 URL 請求來批編譯任何應用程式。如同 ASP.NET 1.x 一樣，批編譯消除了第一次頁面請求的延時，但造成了更長的啟動周期。另外，批編譯還要求在部署前編譯程式碼後置檔案。 Web.config 批編譯設定在 ASP.NET 2.0 中仍起作用。批編譯的優點是，第一個使用者可以立即使用頁面，而且在批編譯期間可以檢測到 ASPX 頁中的任何錯誤。但是，批編譯的確增加了應用程式啟動的延時，並且必須要內建在 Web.config 檔案中。應當注意，如果某個檔案出現了問題，則該批將不會接收它。 部署先行編譯 部署先行編譯允許建立一個或多個程式集，這些程式集是 Web 網站的可執行版本。所獲得的程式集包含 Web 網站的已編譯代碼。HTML 頁面、資源、設定檔和 ASPX 頁面被單獨複製。 部署先行編譯要求使用一個稱為 ASPnet_compiler.exe 的命令列公用程式。該公用程式建立一個目標部署目錄，該目錄包含一個含有程式集的 /bin 目錄和各種 ASPX 頁的 stub 檔案。該公用程式還用來在原地進行先行編譯，類似於調用“魔術頁”的行為。stub 檔案分享權限設定 ASPX 頁的名稱，但是包含調用已編譯器集的簡單代碼。換句話說，ASPX 頁只是空殼而不是填滿的功能頁。 通過為部署先行編譯 Web 網站，您可以獲得增強的安全性，因為只有進行反編譯器集才能訪問您的代碼。為了增強保護，可以弄亂所得到的程式集，使您的 Web 應用程式更加安全。部署先行編譯的主要缺點是，在部署前必須執行這些步驟，並且在部署後不能更改 Web 網站。如果想變更，就必須重新編譯該 Web 網站並重新部署它。 對於大多數主要的 Web 應用程式，部署先行編譯選項將是部署的首選機制，因為它減少了在 Web 服務器上部署的原始代碼數量，並提供了最佳的安全性。這個增加的進程可以內建於通常的開發/測試/部署周期中，而工作效率並不會有多大損失。 完整的運行時編譯（\app_code 目錄） 在目前描述的所有三種編譯方法中，在部署前必須要編譯所有的代碼檔案（程式碼後置類別和支援類）。在 ASP.NET 2.0 中，您有代碼目錄。 \app_code 目錄是一個儲存未編譯類的特殊目錄。在運行時，ASP.NET 運行庫將該目錄中的內容編譯到一個程式集中，應用程式中的 ASPX 頁自動引用該程式集。換句話說，通過使用代碼目錄，可以避免為支援代碼建立和引用單獨的程式集。代碼目錄的優點在於，不用完整編譯項目就可以部署，因此減少了不匹配的可能。缺點是，有可能在伺服器上公開未編譯的代碼。 該選項最適合於不需要大量支援代碼（以程式碼後置檔案的形式或外部對象的形式）的 ASP.NET 應用程式。對於一個簡單的應用程式，與更為健壯的編譯方法相比，快速部署和測試系統的功能提供了幾個優點。

選擇最佳的編譯選項要由具體的情況和需要決定，但編譯模型要有靈活性。即使選擇使用 \app_code 目錄來儲存程式碼後置檔案，您仍可以使用完整的編譯方法來部署應用程式。