當前位置:開發者網絡 >> 技術教程 >> .NET教程 >> Asp.Net開發 >> 內容
精彩推薦
分類最新教程
分類熱點教程
    
ASP.NET中新的代碼編譯功能(三)
作者:未知
日期:2005-04-28
人氣:
投稿:(轉貼)
來源:未知
字體:
收藏:加入瀏覽器收藏
以下正文:
預編譯支持

ASP.NET Web 窗體的優勢之一就是增加動態編譯後,您可以很輕鬆地更改 .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 窗體面板!要在 .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 支持,還能查看給定頁面的所有視圖,開發工作不會再因工具限制而局限於某一種樣式。

相關文章: