創(chuàng)建動態(tài)Web頁面的新技術(shù)已經(jīng)以CLR服務(wù)為基礎(chǔ)全部重新改寫。到目前為止，所有.NET提供的語言都可用于編寫ASP.NET頁面，但頁面的擴展名和ASP 3.0的不同。具體地說，簡單Web頁面以“.aspx”為擴展名，Web服務(wù)以“.asmx”為擴展名（來源于“Assembly”），一種稱為Pagelet的ASP.NET頁面可重用部件以“.aspc”為擴展名。

　　 .NET應(yīng)用能夠流暢地同時運行.asp和.aspx頁面。舊式的ASP頁面將由asp.dll直接運行，但它不能利用CLR的功能。

　　 現(xiàn)在，.aspx頁面不再解釋執(zhí)行，而是在第一次調(diào)用出現(xiàn)時被編譯成MSIL代碼，然后再以中間代碼運行，就象J2EE環(huán)境下的JSP一樣。一個合乎邏輯的結(jié)論是性能會有所提升，Microsoft宣稱它可以與Visual Basic 4升級到編譯版本5時應(yīng)用性能的提升程度相媲美。

　　 除了理解VB.NET引入的所有新概念之外，這些根本性的改變還要求對ASP頁面的編寫方式作較大的改動。為了了解從ASP遷移到ASP.NET所要做的工作，下面我們來分析一下主要改動之處。

　　 這些改動分屬三個層次：

API中的改動
頁面結(jié)構(gòu)的改動
VBScript和VB.NET之間的改動
　　 ASP.NET只允許每個頁面使用一種語言。在DNA中，ASP頁面可以同時使用JScript和VBScript；但ASP.NET不再允許這種用法。

　　 在ASP.NET中，函數(shù)必須用HTML < SCRIPT >標(biāo)記包圍，而且不允許把用于生成HTML代碼的函數(shù)分割成多個部分。例如，ASP.NET不允許出現(xiàn)下面這種代碼：

　　 相反，我們必須代之以如下代碼：

< SCRIPT LANGUAGE="VB" runat=server >
Function SayHello()
Response.Write ("< b >< i > ")
Response.Write (" Hello ! ")
Response.Write ("< /i >< /b > ")
End Function
< /SCRIPT >

　　 括起函數(shù)調(diào)用參數(shù)的括號現(xiàn)在是必需的。另外，有的兼容性問題可能源于所有ASP.NET的數(shù)組下標(biāo)都從0開始，而在ASP 3中有的從0開始，有的從1開始。

　　 在VB.NET中，默認(rèn)情況下參數(shù)以值（ByVal）傳遞，而在當(dāng)前的VBScript中，參數(shù)默認(rèn)以引用傳遞（ByRef）。最后，VB.NET將不再支持默認(rèn)值或關(guān)鍵詞Set、Let。

　　 雖然這些改動都不是重大的、根本性的，但如果要利用CLR以及編譯代碼的優(yōu)勢就必須修改現(xiàn)有的代碼，這些改動會占據(jù)開發(fā)者大量的時間。Microsoft已經(jīng)宣布，用于代碼遷移的工具會隨同.NET平臺一起發(fā)布，但從現(xiàn)在起就養(yǎng)成合適的編碼習(xí)慣無疑是有益無害的。

　　 至于COM組件，ASP.NET將采用封裝的形式使得原有的COM組件仍舊能夠運行，但這些COM組件將運行在CLR受管理的環(huán)境之外，而且受管理以及非受管理環(huán)境之間的切換會犧牲一定的性能。因此，很多用戶可能會決定重新把COM組件編寫成COM + 2.0。

　　 ASP.NET引入了服務(wù)器端控件，它可能是ASP.NET吸引開發(fā)者使用它的一個重要原因。使用這些控件，ASP.NET頁面能夠利用可視或者非可視控件提供的如下高級服務(wù)：TreeView（樹形視圖）, ListBox（列表框）, Calendar（日歷），等等。所有這些控件都會分析調(diào)用它們的客戶程序類型，然后生成合適的表現(xiàn)代碼。一般地，Web頁面中的輸入框使用客戶端JavaScript進行輸入合法性驗證，但如果瀏覽器不支持JavaScript或者禁用了JavaScript，用戶輸入驗證就會轉(zhuǎn)到服務(wù)器端。