ASP 遷移到 ASP .NET：需考慮的重要問題

簡介

雖然 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 有關的變化

應用程式配置的變化

狀态管理問題

與安全性有關的變化

資料通路

下面将詳細讨論上述各個方面的變化。

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 屬性，并将代碼與内容真正分開，使代碼可讀性更強。

正如我前面提到過的，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 中，情況有所不同。現在，預設情況下，所有參數都通過值或 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 關鍵字。如果可能，您應該遷移到這種新模式進行錯誤處理，因為它具有更強大、更一緻的應用程式錯誤處理機制。

随着 .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 元件。

現在，您可能會擔心性能問題。由于代理對象而引入了一個額外的層，是以使用 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"/>

模式屬性指定将在何處存儲狀态資訊。可用選項有 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 身份驗證選項

類型 說明

Windows ASP .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 遷移時還會存在問題，因為由于采用了新的編譯模式，每個網頁隻要求一種内嵌 <% %> 語言。但仍然可以使用過去的方式生成用戶端腳本。

總結

正如我們已經了解的，在向 ASP .NET 遷移應用程式之前，有許多問題需要考慮。我在此文中歸納了遷移前後會發生的大多數變化，這應該能使您的遷移過程變得相對簡單一些。

如果您擁有一個大型站點，完成此程序之後，您可能會對遇到并修正了如此多的死代碼、無效代碼以及所有 Bug 而驚奇不已。另外，通常您還可以充分利用 ASP .NET 和 .NET 平台中大量強大的新增功能。