雖然 Microsoft® ASP .NET 的設計者在保持 ASP 應用程序的向后兼容性方面做了大量不懈的努力，但在將 Web 應用程序由 ASP 向 ASP .NET 遷移之前，還是應該了解一下幾個關鍵的問題。在 .NET 平臺和 ASP .NET 中對現有技術進行了改進并采用了一些新技術，透徹理解這些技術有利于簡化此遷移過程，但這需要經過一段漫長的時間。本文探討各方面的變化，以便讓用戶清楚地了解建立 ASP 應用程序并使其在 ASP .NET 環境中運行所必須進行的一些工作。同時，它還指出了 ASP .NET 的一些新特性，用戶可以充分利用這些新特性改進現有的應用程序。但這決不是 ASP .NET 所有新特性的全面介紹，而只是著重探討一下成功遷移時需考慮的一些問題。我設想，由于大多數 ASP 應用程序都使用 Microsoft® Visual Basic® Scripting Edition (VBScript)，所以大多數用戶都會選擇使用 Visual Basic .NET 遷移到 ASP .NET。顯然，這不是必需的。但如果決定在遷移的同時更改語言，將需要進行一些額外的工作，而且很可能還會涉及到設計和結構方面的更改。共存性在討論具體的兼容性和遷移問題之前，了解一下 ASP 和 ASP .NET 如何共存非常重要。ASP 和 ASP .NET 應用程序可以同時在服務器上運行，而互不影響。這主要是由于兩種技術各自使用不同的文件擴展名（.asp 與 .aspx）和不同的配置模型（配置數據庫/注冊表與基于 XML 的配置文件）。這兩種系統還各自具有相應的處理引擎。讓某個應用程序的一部分運行 ASP，而另一部分運行 ASP .NET，這是完全可能的。如果需要將一個快速發展的大型站點一次一小部分地遷移到 ASP .NET，這種特性將對您大有益處。某些用戶可能會說，最好能一次性遷移和部署整個站點。對于某些類型的 Web 應用程序來說也許是如此，但我認為，有許多站點并不能這樣：考慮到站點內容和外觀的絕對大小、復雜程度以及迅速變化，這種方式非常缺乏靈活性。畢竟，對于一個盈利的網站來說，那些掏腰包的人不可能允許您停止他們的新增功能，而將整個網站遷移到這種熱門的新技術。另外，如果把向 ASP .NET 遷移作為一項長期投資，您將希望利用此機會盡可能多地對結構和設計做一些改進。綜合這些情況，分階段的共存性遷移是絕對必要的。兼容性問題將應用程序向 ASP .NET 遷移可能不是一件容易的事情；但是，也不應該很困難。ASP .NET 與 ASP 的兼容性非常好，給用戶的感覺就好象 ASP .NET 是 ASP 的一個完整翻版。ASP .NET 設計者的最初目標是實現與 ASP 百分之百的向后兼容性，但在隨后的工作中，他們不得不改變了這一初衷，以便徹底地改進這一平臺。不過不要擔心，我們盡可能進行了大量改進，應該不會需要您進行太多的工作。所發生的實際變化可以歸納為下列幾類： 核心 API 的變化 結構變化 Visual Basic 語言的變化 與 COM 有關的變化 應用程序配置的變化 狀態管理問題 與安全性有關的變化 數據訪問 下面將詳細討論上述各個方面的變化。核心 API 的變化ASP 的核心 API 由幾個固有對象（Request、Response 和 Server 等）及其有關方法組成。除幾處簡單變化之外，這些 API 在 ASP .NET 下可以繼續正常運行。所有變化都與 Request 對象有關，如表 1 所示：表 1：API 的變化方法變化Request(item)在 ASP 中，此方法返回字符串數組。在 ASP .NET 中，它返回 NameValueCollection。Request.QueryString(item)在 ASP 中，此方法返回字符串數組。在 ASP .NET 中，它返回 NameValueCollection。Request.Form(item)在 ASP 中，此方法返回字符串數組。在 ASP .NET 中，它返回 NameValueCollection。正如您所見，對于涉及到的所有方法，其變化基本上都相同。如果訪問的 item（項）只包含特定關鍵字的一個值，您將不必修改自己的代碼。但是，如果給定的關鍵字具有多個值，您將需要使用其它方法返回值的集合。另請注意，Visual Basic .NET 中的集合都是基于 0，而 VBScript 中的集合是基于 1 的。例如，在 ASP 中，將按下列方式訪問 http://localhost/myweb/valuetest.asp?values=10&values=20 請求返回的各個查詢字符串值：<% '輸出“10” Response.Write Request.QueryString("values")(1) '輸出“20” Response.Write Request.QueryString("values")(2)%>在 ASP .NET 中，QueryString 屬性返回 NameValueCollection 對象，在檢索所需的實際項之前，將需要從該對象中檢索 Values 集合。另外需要注意，集合中的第一項是使用 0 而非 1 索引進行檢索的：<% '輸出“10” Response.Write (Request.QueryString.GetValues("values")(0)) '輸出“20” Response.Write (Request.QueryString.GetValues("values")(1))%>下列代碼在 ASP 和 ASP .NET 中的運行結果相同：<% '輸出“10”和“20” Response.Write (Request.QueryString("values"))%>結構變化結構變化將影響 Active Server Pages 的布局和編碼樣式。您需要了解其中的一些信息，以確保您的代碼能夠在 ASP .NET 中運行。代碼塊：聲明函數和變量在 ASP 中，可以在代碼分隔符之間聲明子程序和全局變量。<% Dim X Dim str Sub MySub() Response.Write "這是一個字符串。" End Sub %>在 ASP .NET 中，不允許以這種方式進行聲明。您必須在 <script> 塊中聲明所有函數和變量。<script language = "vb" runat = "server"> Dim str As String Dim x, y As Integer Function Add(I As Integer, J As Integer) As Integer Return (I + J) End Function</script>混合編程語言在 ASP 中，基本上有兩種編程語言供您選擇：VBScript 或 Microsoft® JScript®。在同一網頁中，您可以隨意組合和匹配各種腳本塊。在 ASP .NET 中，目前有三種語言可供您選擇：C#、Visual Basic .NET 或 JScript。注意，我說的是 Visual Basic .NET，而不是 VBScript。這是因為 .NET 平臺上不存在 VBScript，它已被完全集成到 Visual Basic .NET 中。雖然可以自由選擇其中的任意一種語言，但需要注意的是，您不能像在 ASP 中那樣在同一網頁中使用多種語言。您的確可以在同一個應用程序的 Page1.aspx 中使用 C# 代碼，而在 Page2.aspx 中使用 Visual Basic .NET 代碼，只是您不能在同一頁中混用它們。新增的 Page 指令在 ASP 中，必須將所有指令置于網頁中同一分隔塊內的第一行。例如：<%LANGUAGE="VBSCRIPT" CODEPAGE="932"%>在 ASP .NET 中，需要將 Language 指令替換為 Page 指令，如下所示：<%@Page Language="VB" CodePage="932"%><%@QutputCache Duration="60" VaryByParam="none" %>可以根據需要包含任意多行指令。指令可以位于 .apsx 文件中的任意位置，但標準做法是將其置于文件的最開頭。在 ASP .NET 中新增了幾個指令。我鼓勵您在 ASP .NET 文檔中查看一下這些指令，了解它們可以為您的應用程序帶來什么樣的好處。生成函數不再有效開發者指出，在 ASP 中，他們可以使用“生成函數”靈活處理一些問題。“生成函數”基本上是一個子程序，在其主體中嵌入了大量 HTML。例如：<%Sub RenderMe()%><H3> 這是正在生成的 HTML 文本。</H3><%End SubRenderMe%>雖然使用這類函數能夠實現非�？岬墓δ�，但 ASP .NET 中不允許使用這類編碼。這可能是出于優化性能的考慮。我想您肯定遇到過，像這樣將代碼與 HTML 混在一起時，有些函數很快就變得可讀性極差，而且難以管理。在 ASP .NET 中，實現此目的的最簡單方法是調用 Response.Write 來代替 HTML 輸出，如下所示：<script language="vb" runat="server"> Sub RenderMe() Response.Write("<H3> 這是正在生成的 HTML 文本。</H3>") End Sub</script><% Call RenderMe()%>注意，我說的是“最簡單的方法”，但并不一定表示是最佳方法。根據生成代碼的復雜程度和數量，使用自定義 Web 控件效果可能更好，這種控件允許您通過編程設置 HTML 屬性，并將代碼與內容真正分開，使代碼可讀性更強。Visual Basic 語言的變化正如我前面提到過的，VBScript 已集成到了更完整、功能更強大的 Visual Basic .NET 中。這一節，我將重點講述您可能會遇到的與 Visual Basic 語言變化有關的一些問題。但需注意，這并不是詳盡的 Visual Basic 變化列表。我只是著重講述作為一名 ASP/VBScript 程序員，在使用 Visual Basic .NET 向 ASP .NET 遷移時可能會遇到的一些問題。有關所有語言變化的詳盡列表，請參見 Visual Basic .NET 文檔。告別 Variant 數據類型我們熟悉它、喜歡它，對它又愛又恨。當然，我說的是 VARIANT 數據類型。.NET 中沒有 VARIANT，因此 Visual Basic .NET 不支持這種數據類型。這意味著，您的所有 ASP 變量將悄悄地由 VARIANT 類型更改為 Object 類型。根據需要，應用程序中使用的大量變量可以而且應該更改為相應的基元類型。如果您的變量實際上是 Visual Basic 中的 object 類型，則只需在 ASP .NET 中將其顯式聲明為 Object 類型。 Visual Basic Date 類型值得特別注意的一種 VARIANT 類型是 VT_DATE，它在 Visual Basic 中以 Date 類型出現。在 Visual Basic 中，使用四個字節以 Double 格式存儲 Date。在 Visual Basic .NET 中，Date 使用公共語言運行庫 DateTime 類型，該類型使用八個字節整數表示。 由于 ASP 中的所有類型都是 VARIANT，對于所需的 Date 變量，將根據它們的使用方式進行編譯并可以繼續使用。但是，使用變量執行某些操作時，由于基本類型已發生變化，所以可能會遇到一些意想不到的問題。在將日期值作為長整型值傳遞給 COM 對象時，或使用 CLng 對日期類型執行某些計算時，需特別注意。Option Explicit 現在是默認值在 ASP 中，可以使用 Option Explicit 關鍵字，但它不是默認值。在 Visual Basic .NET 中，情況有所不同。Option Explicit 現在是默認值，因此，所有變量都需要聲明。更嚴格地要求聲明并將設置更改為 Option Strict 是一種比較明智的作法。這樣做將迫使您將所有變量聲明為特定的數據類型。乍看起來這是一項額外的工作，但實際上這是正確的做事方式。如果不這樣做，您的代碼將達不到最優狀態，因為所有未聲明的變量都將更改為 Object 類型。大多數隱式約定仍然有效，但如果將所有變量顯式聲明為所需類型，則能達到更好的效果，而且更安全。不再支持 LET 和 SET可以將一個對象直接賦值給另一對象，如 MyObj1 = MyObj2，而不再需要使用 SET 或 LET 語句。如果使用了這些語句，必須將其刪除。在方法調用中使用括號在 ASP 中，您可以任意調用對象方法，而不必使用括號，如下所示：Sub WriteData() Response.Write "這是數據"End SubWriteData在 ASP .NET 中，所有調用都必須使用括號，即使是調用不帶任何括號的方法。如下例所示編寫代碼，使其在 ASP 和 ASP .NET 中都可以正確運行。Sub WriteData() Response.Write("這是數據")End SubCall WriteData()ByVal 現在是默認值在 Visual Basic 中，默認情況下，所有參數都通過引用或 ByRef 進行傳遞。在 Visual Basic .NET 中，情況有所不同�，F在，默認情況下，所有參數都通過值或 ByVal 進行傳遞。如果仍要使用 ByRef，必須在參數前面顯式使用 ByRef 關鍵字，如下所示：Sub MyByRefSub (ByRef Value) Value = 53;End Sub這一點必須特別注意。向 ASP .NET 遷移代碼時，建議您仔細檢查方法調用中使用的每個參數，確保這種變化是您真正需要的。我想您可能需要更改其中的某些參數。不再有默認屬性在 Visual Basic .NET 中，不再存在默認屬性的概念。這就意味著，如果您的 ASP 代碼依賴于某個對象提供的默認屬性，則需要更改為顯式引用所需屬性，如下列代碼所示：'ASP 語法（隱式檢索 Column Value 屬性）Set Conn = Server.CreateObject("ADODB.Connection")Conn.Open("TestDB")Set RS = Conn.Execute("Select * from Products")Response.Write RS("Name")'ASP.NET 語法（顯示檢索 Column Value 屬性）Conn = Server.CreateObject("ADODB.Connection")Conn.Open("TestDB")RS = Conn.Execute("Select * from Products")Response.Write (RS("Name").Value)數據類型的變化在 Visual Basic .NET 中，Integer 值現在是 32 位，Long 類型已變成 64 位。從 ASP .NET 中調用 COM 對象方法時，或調用自定義 Visual Basic 組件中的 Microsoft® Win32® API 調用時，可能會出現問題。應特別注意需要的實際數據類型，確保傳遞或計算的值正確。結構化異常處理雖然人們所熟悉的 On Error Resume Next 和 On Error Goto 錯誤處理技術在 Visual Basic .NET 中仍可使用，但它們不再是進行錯誤處理的最佳方法。Visual Basic 現在具有一種完善的結構化異常處理方法，它使用 Try、Catch 和 Finally 關鍵字。如果可能，您應該遷移到這種新模式進行錯誤處理，因為它具有更強大、更一致的應用程序錯誤處理機制。與 COM 有關的變化隨著 .NET 框架和 ASP .NET 的誕生，COM 實際上沒有發生任何變化。但這并不表示在 ASP .NET 中使用 COM 對象時不必擔心和考慮他們的行為。有一些基本情況，您必須了解。線程模式的變化ASP .NET 線程模式是多線程單元 (MTA)。這就意味著，對于目前使用的為單線程單元 (STA) 創建的組件，如果不采取額外的措施，將不能在 ASP .NET 中可靠地執行或運行。其中包括但不限于使用 Visual Basic 6.0 及其更低版本創建的所有 COM 組件。ASPCOMPAT 屬性您將很高興聽到這樣一個消息：仍然可以使用這些 STA 組件，而不需要更改任何代碼。您需要做的工作只是在 ASP .NET 網頁的 <%@Page> 標記中包含兼容性屬性 aspcompat=true，如 <%@Page aspcompat=true Language=VB%>。使用此屬性將強制網頁以 STA 模式執行，從而確保您的組件可以繼續正確運行。如果試圖使用 STA 組件但沒有指定此標記，運行時將會發生異常情況。將此屬性的值設置為 true 時，將允許網頁調用 COM+ 1.0 組件，該組件需要訪問非管理的 ASP 內置對象�？梢酝ㄟ^ ObjectContext 對象進行訪問。如果將此標記的值設為 true，性能會稍微有些下降。建議只在確實需要時才這樣做。早期綁定與后期綁定在 ASP 中，對 COM 對象的所有調用都是通過 IDispatch 接口進行的。這種行為被稱為“后期綁定”，因為對實際對象的調用是在運行時通過 IDispatch 間接處理的。在 ASP .NET 中，只要您愿意，可以繼續以這種方式調用您的組件。Dim Obj As ObjectObj = Server.CreateObject("ProgID")Obj.MyMethodCall仍然可以使用這種方式訪問您的組件，但這不是首選方式。現在，在 ASP .NET 中，您可以利用早期綁定直接創建對象，如下所示：Dim Obj As New MyObjectMyObject.MyMethodCall()使用早期綁定，可以通過類型安全的方式與組件交互。為了在 COM 組件中使用早期綁定，您需要像在 Visual Basic 6.0 項目中添加 COM 引用一樣，在項目中添加一個引用。假設您正在使用 Visual Studio .NET，將在 COM 組件之上后臺創建一個管理的代理對象，給您的感覺就好像是直接在處理一個 .NET 組件，而不是 COM 組件�，F在，您可能會擔心性能問題。由于代理對象而引入了一個額外的層，所以使用 COM 協同操作時確實會存在一些問題。但是，大多數情況下，應該不會遇到什么問題，因為進行協同操作的實際 CPU 指令數仍然遠遠小于間接 IDispatch 調用的要求。您所得到的將遠遠超出您所失去的。當然，理想情況是使用最新創建的管理對象，但我們知道，由于我們在 COM 組件上的投入所限，并不總是能夠立即做到這一點。OnStartPage 和 OnEndPage 方法需要特別注意的是對舊版 OnStartPage 和 OnEndPage 方法的使用。如果您依賴于這些方法訪問 ASP 固有對象，將需要使用 ASPCOMPAT 指令和 Server.CreateObject 以早期綁定方式創建組件，如下所示：Dim Obj As MyObjObj = Server.CreateObject(MyObj)Obj.MyMethodCall()注意，我們并沒有使用“ProgID”，而是以早期綁定方式使用實際類型。為了讓這種方式有效，您需要在 Visual Studio 項目中添加 COM 組件引用，這樣才能創建早期綁定的包裝類。這是唯一必須繼續使用 Server.CreateObject 的情況。COM 總結表 2 總結了為繼續有效使用 COM 組件而必須完成的一些工作。表 2：舊版 COM 對象的 ASP .NET 設置COM 組件類型/方法ASP .NET 設置/過程自定義 STA（標記為“Apartment”的 Visual Basic 組件或其它組件）使用 ASPCOMPAT 和早期綁定自定義 MTA（標記為“Both”或“Free”的 ATL 或自定義 COM 組件）不使用 ASPCOMPAT，使用早期綁定固有對象（通過 ObjectContext 訪問）使用 ASPCOMPAT 和早期綁定OnStartPage 和 OnEndPage使用 ASPCOMPAT 和 Server.CreateObject(Type)無論您的組件是否部署在 COM+ 中，都將同樣應用這些設置。應用程序配置的變化在 ASP 中，所有 Web 應用程序配置信息都存儲在系統注冊表和 IIS 配置數據庫中。由于服務器上經常未安裝適當的管理工具，使得查看或修改設置變得非常困難。ASP .NET 引入了一整套全新的配置模型，這套模型以簡單的、易讀的 XML 文件為基礎。每個 ASP .NET 應用程序都有自己的 Web.Config 文件，該文件位于主應用程序目錄中�？梢酝ㄟ^此文件控制 Web 應用程序的自定義配置、行為和安全性。如果您與我一樣，您可能會通過“Internet 服務管理器”管理單元檢查和更改 ASP .NET 應用程序的設置。但是，您必須了解，現在我們擁有兩種完全不同的配置模型。除一些安全性設置外，ASP .NET 應用程序將忽略使用 IIS 管理工具配置的其它大部分設置。您需要將這些配置設置保存在 Web.Config 文件中。有關 .NET 的應用程序配置將在另一篇文章中詳細討論，此處就不詳細介紹了。表 3 說明了可以在自己的文件中配置的一些更有意義的設置。記住，還有更多設置。表 3：Web.Config 設置示例設置說明<appSettings>配置自定義應用程序設置。<authentication>配置 ASP .NET 身份驗證支持。<pages>標識網頁特定的配置設置。<processModel>配置 IIS 系統中的 ASP .NET 進程模型設置。<sessionState>指定會話狀態選項。在 .NET 基本類庫中還有其它一些類可用，它們簡化了對這些設置的編程訪問。狀態管理如果應用程序使用 Session 或 Application 固有對象存儲狀態信息，則在 ASP .NET 中可以繼續使用這些對象，而不會出現任何問題。隨之帶來的好處是，現在提供了更多的狀態存儲位置選項。狀態管理選項ASP .NET 中還包含其它一些狀態管理模型選項，最終可使您管理不止一個 Web 服務器，并支持通過 Web 場進行狀態管理�？梢栽� web.config 文件的 <sessionState> 一節中配置狀態管理選項，如下所示：<sessionState mode="Inproc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;user id=sa;password=" cookieless="false" timeout="20"/>模式屬性指定將在何處存儲狀態信息�？捎眠x項有 Inproc、StateServer、SqlServer 或 Off。表 4：會話狀態存儲信息選項說明Inproc會話狀態本地存儲在此服務器中（ASP 樣式）。StateServer會話狀態遠程（或本地）存儲在狀態服務進程中。SqlServer會話狀態存儲在 SQL Server 數據庫中。Off會話狀態被禁用。如果使用這些選項之一，StateConnectionString 和 sqlConnectionString 無疑將成為至關重要的參數。每個應用程序只能使用一個存儲選項。存儲 COM 組件需記住的的一點是，如果您依賴于對 Session 或 Application 對象中舊版 COM 組件的存儲引用，將無法在應用程序中使用新的狀態存儲機制（StateServer 或 SqlServer）。您將需要使用 Inproc。部分原因是對象需要在 .NET 中實現自我串行，很顯然，COM 組件無法做到這一點。另一方面，新創建的管理組件可以相對輕松地實現這一點，因此可以使用新的狀態存儲模式。性能當然，就性能而言，每前進一步都將付出相應的代價。但您完全可以相信，大多數情況下，使用 Inproc 依然是最佳選擇，其后依次是 StateServer 和 SqlServer。您自己應該對應用程序進行測試，確保選定的選項可以達到您的性能目標。ASP 和 ASP .NET 之間的共享狀態需要考慮的另外一個重要問題是，雖然應用程序可以同時包含 ASP 和 ASP .NET 網頁，但您無法共享固有 Session 或 Application 對象中存儲的狀態變量�？赡苄枰獙⑦@些信息復制到這兩個系統中或提出其它自定義解決方案，才能完全遷移您的應用程序。最好的情況是您未使用 Session 和 Application 對象。另一方面，如果您大量使用了這些對象，您需要一直小心謹慎，或許可以提出某種自定義的短期解決方案來共享狀態。與安全性有關的變化安全性是需要特別注意的另一個重要問題。下面簡要介紹了 ASP .NET 安全性系統。有關安全性問題更完整的研究，請參見 ASP .NET 安全性文檔。ASP .NET 安全性主要受 web.config 文件中安全性部分的設置控制。ASP .NET 與 IIS 協同工作，為您的應用程序提供完善的完全性模型。IIS 安全性設置是實際攜帶并應用于 ASP .NET 應用程序的少數幾個應用程序設置，其攜帶和應用方式與在 ASP .NET 中相似。當然，在很多方面都得到了改進。身份驗證對于身份驗證，ASP .NET 支持表 5 中所示的選項。表 5：ASP .NET 身份驗證選項類型說明WindowsASP .NET 使用 Windows 身份驗證。Forms基于 Cookie 的自定義登錄表單。Passport非 Microsoft 提供的 Passport Service。None不執行身份驗證。除新增加的 Passport 身份驗證選項之外，其它選項都與 ASP 中的選項相同。例如，下列配置對應用程序啟用基于 Windows 的身份驗證。<configuration> <system.web> <authentication mode="Windows"/> </system.web></configuration>授權用戶通過身份驗證后，將集中考慮允許他們訪問哪些資源。在下例中，授予了“jkieley”和“jstegman”訪問權限，而其他所有人都被拒絕訪問。<authorization> <allow users="NORTHAMERICA\jkieley, REDMOND\jstegman"/> <deny users="*"/></authorization>模擬做為刷新程序，模擬是指這樣一個過程：對象以它所代表的實體的標識執行代碼。在 ASP 中，模擬允許您的代碼代表通過身份驗證的用戶運行�；蛘�，用戶也可以通過特定標識匿名運行。默認情況下，ASP .NET 不會針對每個請求進行模擬。這一點與 ASP 不同。如果您依賴于這種功能，則需要在 web.config 文件中啟用它，如下所示：<identity> <impersonation enable = "true"/></identity>數據訪問遷移過程中，需要重點考慮的另一個關鍵問題是數據訪問。隨著 ADO .NET 的誕生，現在您具有了一種訪問數據的強有力的全新方法。由于數據訪問本身就是一個很大的主題，本文就不詳細討論了。大多數情況下，您可以像過去一樣繼續使用 ADO，但是我極力推薦您了解一下 ADO .NET，并通過它改善 ASP .NET 應用程序中的數據訪問方法。準備向 ASP .NET 遷移現在您已了解了可能會遇到的大多數問題，您可能會想：目前我需要做好哪些準備工作以備將來最終遷移到 ASP .NET 呢？目前確實需要完成幾項工作，以確保將來的遷移過程順利進行。其中的許多建議對您的 ASP 代碼大有益處，即使目前不打算向 ASP .NET 遷移。使用 Option Explicit這始終是一個不錯的建議，但至今仍然有許多人沒有使用它。通過使用 Option Explicit，強制在 ASP 中聲明變量，您至少可以控制在何處定義每個對象以及如何使用變量。遷移到 ASP .NET 之后，我建議使用 Option Strict。在 Visual Basic .NET 中，默認使用 Option Explicit，但是使用更具強制性的 Option Strict，可以確保所有變量都聲明為正確的數據類型。這樣做確實需要增加一些額外的工作，但從長期考慮，您將發現還是很值得這樣做的。避免使用默認屬性我們前面已討論過，不再允許使用默認屬性。顯式訪問屬性并不是什么難事。它將增強代碼的可讀性，而且可以在將來節省您的時間。使用括號和 Call 關鍵字正如本文前面詳細討論過的，應盡可能使用括號和 Call 語句。在 ASP .NET 中，將強制使用括號。現在使用 Call 語句有助于您熟悉一些規則，為將來的工作打好基礎。避免嵌套的包含文件這一點可能說起來容易做起來難，但還是應盡可能避免嵌套包含文件。我的意思是說，應該努力避免在包含文件中包括其它包含文件。隨著時間的推移，可能會碰到的一種情況是，您的代碼不再依賴于在其它某處的包含文件中定義的全局變量，您需要訪問的原因僅僅是因為其中嵌套了包含您真正需要的全局變量的另一個文件。向 ASP .NET 遷移時，您很有可能會將全局變量和程序遷移到類庫中，這種情況下，如果您清楚地了解每個對象的訪問位置，遷移起來就很容易。您不需要將一些對象移來移去，也不需要更改多個文件中相同的那些程序名稱。將實用函數合并到單個文件中遷移過程中的一個策略是將服務器端包含文件中包含的所有實用函數和代碼遷移到 Visual Basic 或 C# 類庫中。這樣，您最終可以將所有代碼放到所屬對象中，這一點與多解釋的 ASP 文件不同。提前組織好代碼，可以節省將來的遷移時間。理論上講，您應該可以將子程序組合到邏輯文件中，從而使您可以輕松地創建一組 VB 或 C# 類。這些函數可能應位于 COM 對象中。如果服務器端包含文件中存在一大堆全局變量或常量，也最好考慮將他們組合到單個文件中。一旦遷移到 ASP .NET 后，您就可以輕松創建一個類來存放全局或常量數據。這將使系統更干凈、更易維護。盡可能將代碼與內容分開這又是一件說起來比做起來容易的工作，但是您應該盡量將代碼與 HTML 內容分開。清理一下主體中即有代碼、又有腳本的那些函數。這樣做使您處于非常有利的位置，可以充分利用代碼--無論怎么說，這是 ASP .NET 中的最佳模式。不要在 <% %> 塊聲明函數ASP .NET 不支持在 <% %> 塊聲明函數。應該在 <script> 塊進行聲明。有關此技術的示例，請參閱本文前面的結構變化一節。避免使用生成函數如前所述，應該盡量避免使用“生成函數”。如果現在可以更改或準備代碼，應在構造這類函數時使用 Response.Write 塊。顯式釋放資源（調用 Close 方法）確保對使用的對象和資源中存在的 close() 或清理方法進行顯式調用。我們都知道，Visual Basic 和 VBScript 在清理方面的容錯能力很強。通常情況下，他們能夠立即清理對象。但遷移到 .NET 后，您將無法準確掌握對象何時會被清理，就像您無法確定垃圾堆中的垃圾何時會被清理一樣。如果您能夠顯式清理和釋放資源，最好顯式地進行清理和釋放。避免混用語言應該盡量避免在同一網頁中混用服務器端 VBScript 和 JScript。一般而言，這是一種不太明智的編程方式。而且向 ASP .NET 遷移時還會存在問題，因為由于采用了新的編譯模式，每個網頁只要求一種內嵌 <% %> 語言。但仍然可以使用過去的方式生成客戶端腳本�？偨Y正如我們已經了解的，在向 ASP .NET 遷移應用程序之前，有許多問題需要考慮。我在此文中歸納了遷移前后會發生的大多數變化，這應該能使您的遷移過程變得相對簡單一些。如果您擁有一個大型站點，完成此進程之后，您可能會對遇到并修正了如此多的死代碼、無效代碼以及所有 Bug 而驚奇不已。另外，通常您還可以充分利用 ASP .NET 和 .NET 平臺中大量強大的新增功能。