asp.net|編譯 先行編譯支援
ASP.NET Web Form的優勢之一就是增加動態編譯後，您可以很輕鬆地更改 .aspx 頁，儲存更改時頁面將動態更新，而不需要重新編譯（只要不使用模組化代碼）。但動態編譯並不是對每個應用程式都適合，而且第一次訪問某個應用程式時，動態編譯會導致瀏覽器的初始效能降低。另外，很多時候您可能希望部署一個沒有原始碼的應用程式。如果您遇到上述情況，您會更高興地瞭解到 ASP.NET Whidbey 具有支援先行編譯 Web 網站的功能。ASP.NET Whidbey 支援兩種先行編譯模式：在位先行編譯和部署先行編譯。
在位先行編譯
在位先行編譯使您可以對 Web 網站中的所有頁面進行手動批編譯。這也是使用者在您的應用程式中首次單擊某個頁面後發生的操作（前文提到的後一種情況除外），使用者只需坐下來等待批編譯完成。使用在位先行編譯有兩個主要原因：首先，它可以避免第一次請求頁面時批編譯的效能降低；其次，它使您可以“先於”使用者發現編譯錯誤。
在位先行編譯也很容易實現，只需瀏覽到 Web 網站的根目錄，添加特定的處理常式名稱 precompile.axd（熟悉 ASP.NET 跟蹤功能的使用者會發現該名稱與 trace.axd 處理常式的名稱類似）：
http://localhost/mywebsitename/precompile.axd
其中 mywebsitename 是您 Web 網站的名稱。先行編譯網站之後，對網站內頁面的請求也應隨即完成，而不會有任何編譯滯後。
部署先行編譯
第二種先行編譯模式使您可以建立整個 Web 網站的可執行版本，部署這種版本不需要任何原始碼（包括 HTML 和其他靜態檔案）。因此，部署先行編譯可以防止別人隨意訪問由代碼錶示的智慧財產權資訊。產生的程式集和 Stub 檔案集可以通過 XCOPY、FTP、Windows 資源管理員等部署到生產伺服器上。為了先行編譯網站以進行部署，ASP.NET Whidbey 提供了一個名為 aspnet_compiler.exe 的命令列公用程式。要在檔案系統 Web 網站上調用 ASP.NET 先行編譯器，需要開啟一個命令視窗，瀏覽到 .NET Framework 的安裝位置（\Microsoft.NET\Framework\<版本>），然後輸入以下命令：
aspnet_compiler /v /<websitename> -p <source> <destination>
其中 為 Web 網站的名稱（即在瀏覽器中輸入的名稱）， 和 為兩個檔案系統路徑，分別指向要編譯網站的位置以及編譯後的版本應輸出至的位置。以我們的 Web 網站為例，輸入的命令如下所示（請注意下面是一條命令）：
aspnet_compiler /v /Compilation -p c:\WebSites\Compilation c:\WebSites\Compilation_Compiled
如果要查看 ASP.NET 先行編譯器的所有可用選項，只需輸入以下命令：
aspnet_compiler /?
請注意，某些命令列選項要求 Web 網站必須為有效 Microsoft® Internet 資訊服務 (IIS) 應用程式才能正常工作。如果在 Microsoft® Windows 資源管理員中瀏覽至目標目錄，您會看到先行編譯 Web 網站後將產生一個包含 bin 目錄的網站，bin 目錄中包含一些程式集和描述性檔案，以及大量與原始頁面同名的 Stub 檔案，但不包含代碼（包括 HTML 和可執行代碼）。如果瀏覽此網站，輸出與原始網站的輸出相同。請注意，不能在已進行部署先行編譯的網站上使用在位先行編譯，原因很簡單，因為它已經被先行編譯過了。
IntelliSense 無處不在！
對於 Visual Studio .NET 2002 和 2003，最令我頭痛的問題之一（相信很多開發人員也有同感）就是對 IntelliSense 和其他用於提高生產率的功能的支援不一致。希望在 HTML 視圖中將控制項從工具箱中拖到頁面上嗎？還做不到。事實上，在 HTML 視圖中根本看不到工具箱的 Web Form面板！要在 .aspx 頁面上寫入內嵌代碼而不是使用模組化代碼？可以做到，但必須放棄 IntelliSense、拖放功能以及其他更多功能。最後，正如我最近在 MSDN ASP.NET Developer Center 上發表的文章中提到的，在 Visual Studio .NET 2002 或 2003 中獲得自訂控制項的設計時支援需要跨越層層障礙，包括有點粗糙但奏效的 XSL 修改。
令人高興的是，ASP.NET Whidbey 中實現了編譯模型的統一，所有這些問題也都迎刃而解。在 Visual Studio .NET Whidbey 中，可以寫入內嵌代碼或使用新的模組化代碼模型，還能獲得控制項拖放、IntelliSense 陳述式完成以及所有以前您希望使用卻因編碼方式局限而無法使用的那些可以提高生產率的功能。另外，對自訂伺服器控制項和 Web 控制項的設計時支援有了很大的改進，包括為源視圖（HTML 視圖在 Visual Studio .NET Whidbey 中的等效視圖）中的自訂控制項增加了 IntelliSense 陳述式完成。
小結
ASP.NET Whidbey 中對編譯模型的更改，以及 Visual Studio .NET Whidbey 中相應功能的改進無疑是一個巨大的飛躍，不僅為開發人員提供了所需的靈活性，還使他們可以充分利用 IDE 提供的可以提高生產率的功能。大大簡化的模組化代碼模型將使該功能更有用、更簡捷，而新增的對內嵌代碼的完全支援顯然會受到那些希望所有代碼都位於一個 .aspx 檔案中的開發人員的歡迎。相信 \Code 目錄會大大提高生產率，對於那些從事發展迅速的中小型項目的開發人員，以及那些因為編譯過程過於複雜而無法完成工作的開發人員來說尤其如此。它還為訪問商務邏輯組件、資源檔、WSDL 檔案以及其他資源提供了一種更為直接、簡單的方法：通過自動編譯、嵌入或建立這些資源的代理並自動引用它們，只需很少的代碼即可訪問這些資源。
先行編譯功能使開發人員可以輕鬆地提高其網站的初始效能，如果需要，還可以通過提供功能完備的 Web 應用程式（不包含原始碼或 HTML）為重要的智慧財產權資訊添加保護措施。最後，集所有功能於一身的 Visual Studio .NET Whidbey 無疑會為開發人員帶來非凡的體驗，他們不僅能從內嵌代碼模型和模組化代碼模型中獲得完全的 IntelliSense 支援，還能查看給定頁面的所有視圖，開發工作不會再因工具限制而局限於某一種樣式。
