asp.net'ASP Syntax (Implicit retrieval of Column Value property)
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("TestDB")
Set RS = Conn.Execute("Select * from Products")
Response.Write RS("Name")

'ASP.NET Syntax (Explicit retrieval of Column Value property)
Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("TestDB")
RS = Conn.Execute("Select * from Products")
Response.Write (RS("Name").Value)


数据类型的变化

在Visual Basic .NET，整数值现在是32 位。Long数据类型为64 位。

当从ASP.NET中调用COM对象的方法或是在您自定义Visual Basic components组件中调用Microsoft® Win32® API，都可能发生问题。您特别要注意实际需要的数据类型，以确保您正确传递数值。


结构化的例外处理

虽然在Visual Basic .NET中，仍然沿用熟悉的On Error Resume Next 及On Error Goto　错误处理方法，但是，它们不再是最好的方法。Visual Basic现在有成熟的,系统的例外处理方法。它们使用Try, Catch, 及 Finally等关键字。如果有可能的话，您应该转向这种新的错误处理模式，因为它运用了一个性能更加完善，稳定的机制来处理应用程序错误。
　
与前面介绍的.NET 框架与ASP.NET相比,COM基本没有变化。但是，这并不是说您从ASP.NET上运用它们时，您完全不需要顾及COM对象及它们的行为。以下是几点您必须注意的要素：


线程模式变化

ASP.NET线程模式是Multiple Threaded Apartment (MTA).　这就是说，您所用的为Single Threaded Apartment (STA)而生成的组件，在ASP.NET中，如不采取特别预防措施，不再会可靠工作。这包括，但不局限于，用Visual Basic 6.0及先前版本生成的所有COM组件。


ASPCOMPAT 属性

现有的STA组件不需要任何修改就能使用。 您所要做的仅仅是在ASP.NET页面的<%Page>标签中加入指示兼容的属性aspcompat=true。比如，<%Page aspcompat=true Language=VB%>。使用这个属性会强制该页面在STA模式下执行，从而确保您的组件正常工作。如果您的页面不指定本属性而直接引用STA组件，在运行时将发生异常。

设置aspcompat=true也将使您的页面能够调用那些需要使用ASP内建对象的COM+1.0组件。这可以通过ObjectConect对象来实现。

设置本属性会导致一定的性能下降。我建议您仅在必要的情况下使用它。


预先绑定与滞后绑定

在ASP中，所有对COM组件的调用都是通过IDispatch接口进行的。由于所有调用都需要在运行时由IDispatch间接处理，我们称之为滞后绑定。在ASP.NET中，如果您愿意，您仍然可以使用这种方式来完成对象调用。
Dim Obj As Object
Obj = Server.CreateObject("ProgID")
Obj.MyMethodCall

以上代码能够工作，但这并不是我们所推荐的用法。在ASP.NET中，您可以利用预先绑定直接创建您需要的对象：
Dim Obj As New MyObject
MyObject.MyMethodCall()

预先绑定能使您的页面在与组件的交互过程中避免出现类型错误。为了使用预先绑定，您需要在项目中加入一个引用，正如您在VB6.0项目中加入一个COM组件引用一样。假设您使用的开发工具是Visual Studio.NET，VS.NET将会在后台创建一个位于COM组件之上的代理对象，让您感到就像在使用.NET组件一样方便。

至此您可能会提出性能问题。为了保证与COM的互操作性，我们引入了代理对象，这的确会带来一定的性能负担。然而，在大多数情况下，您并不需要担心由此而引发的性能下降。毕竟，与冗长的IDispatch调用相比，代理对象所执行的CPU指令几乎可以忽略不计。您所赢得的远远超过您所失去的性能。当然，理想的状况是完全使用新创建的，被管理的(Managed)对象。然而，理想状况近期还不可能达到——我们必须保护在过去几年里对COM技术的投资。


OnStartPage和OnEndPage方法

在使用传统的OnStartPage和OnEndPage方法问题上，您可能需要多花一些时间。如果您依赖于这两个方法来访问ASP固有对象，那么您需要使用ASPCOMPAT指令，然后用Server.CreateObject以预先绑定的方式来创建对象。见下例：
Dim Obj As MyObj
Obj = Server.CreateObject(MyObj)
Obj.MyMethodCall()

请注意我们没有用“ProgID”，而是用了预先绑定的实际对象类型。为了保证以上代码正常工作，您需要在Visual Studio项目中加入对该COM组件的引用，以便VS创建一个预先绑定的包装类。这里是您必须继续使用Server.CreateObject的唯一理由。


COM小结

表2列出了您为了继续有效使用现有的COM组件所必须做的事情。

表2. 传统COM对象的ASP.NET设置

COM 组件类型/方法
　ASP .NET 设置/例程

Custom STA (Visual Basic 组件 或其它被标志为"Apartment"的组件)  
　使用 ASPCOMPAT属性, 和预先绑定  
Custom MTA (或其它被标志为"Both" or "Free" 的ATL 或自定义的 COM组件)
　使用预先绑定,不当但不要用 ASPCOMPAT属性  
内置对象 (通过ObjectContext 对象来访问)
　使用 ASPCOMPAT属性, 和预先绑定  
OnStartPage, OnEndPage
　使用 ASPCOMPAT属性, 和Server.CreateObject(Type)  

无论您的组件是否使用COM+来部署，以上设置都适用。  

在ASP中，Web应用程序的配置信息都存放在系统注册表或IIS的配置数据库(Metabase)中。在很多情况下，由于服务器缺乏适当的管理工具，察看或修改这些设置成为非常困难的一项工作。ASP.NET引入了全新的，基于简单、可读的XML文件的配置模式。ASP.NET应用程序在自己的目录下有一个Web.Config文件。您可以通过修改Web.Config文件来控制应用程序的自定义配置，行为，和改变它的安全属性。  

由于习惯的作用，您可能像我一样还是忍不住要打开Internet Service Manager来查看或修改ASP.NET应用程序的配置。然而，您必须理解，我们现在有两套独立的配置模式。除了一些安全设置，绝大多数由IIS管理工具所生成的设置都会被ASP.NET应用程序忽略。您需要把这些设置放在Web.Config文件里。  

关于.NET应用程序的设置有专门的文章讨论，我这里不再赘述。表3列出了一些比较有趣的配置。请记住还有非常多的配置项目没有列在这张表中。  

表3. Web.Config 文件设置范例  

项目
描述

<appSettings>
　定制应用程序配置  
<authentication>
　设定ASP.NET应用程序对身份验证的支持  
<pages>
　设定页面相关的配置  
<processModel>
　设置ASP.NET在IIS系统中的进程模式  
<sessionState>
　指定一些会话状态选项　

.NET基本类库中有一些类可以用来在程序中简化应用程序配置访问方式。  

如果您的应用程序使用了Session或Application固有对象来存储状态信息，那么它仍然能够在ASP.NET中正确运行。在ASP.NET中，您有了更多的选择来存储状态相关的数据。


可用的状态管理方法

ASP.NET提供了更多的状态存储摸式。这使您的应用程序能够跨越多个Web服务器支持Web farm范围内的状态管理。

您可以用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"
/>

mode属性指定了您想要存储状态信息的位置。您可以选择的状态包括Inproc, StateServer, SqlServer, 及Off。

表 4. 会话状态存储信息

选项
描述

Inproc
　会话状态存储于服务器本地。(ASP 风格)。  
StateServer
　会话状态存储于远程或本地的状态服务进程。  
SqlServer
　会话状态存储于SQL 服务器数据库。  
Off
　会话状态被关闭。  

当你选用StateServer状态，StateConnectionString 会起作用；而当您使用SqlServer状态， sqlConnectionString会起作用。对于每个应用程序，您仅可以使用一个存储选项。


存储COM组件

需要记住的一点是如果您依赖在您的Session 或Application对象中的传统COM组件的存储引用，您就不可以在应用程序中使用新的状态存储机制(StateServer 或SqlServer)。您只能使用Inproc。这是因为在.NET中, 那些对象需要能够自我序列化, 但显然COM 组件做不到. 相反, 您新创建的管理(Managed)组件可以相对容易实现这一点，当然也就可以使用新状态存储模式。

性能

提到性能，当然没有免费可言。可以保证的是，在大多数的情况下，Inproc会继续保持其性能之最。紧随其后的是StateServer和SqlServr。您应当用您的应用程序进行专门测试，以作出最符合您性能要求的选择。


在ASP和ASP.NET中共享状态　

另一个应当注意的问题是虽然您的工具能够容纳ASP和ASP.NET网页，但是您不能共享固有会话或应用对象的状态变量。您可以将信息在两个系统中进行复制，也可以在您的应用程序完全移植前，提供一个自定义的解决方法。底线是：如果您对Session和Application对象运用很少，您不会受到很大影响。但就另一方面而言，如果您对这些对象运用很多，您则需要谨慎的运用。您或许可以考虑采自定义一个短期解决方法以共享状态。

安全性是又一个值得关注的地方。这里提供的是对ASP.NET安全系统的简要概括。要获得更详尽的信息，请参阅ASP.NET安全系统的有关文件。

ASP .NET的安全性主要由web.config文件中的安全设置部分来控制。ASP .NET与IIS协调一致，紧密配合，为您的应用程序提供一个完整的安全模式。一些极少数的IIS 安全性设置会以在ASP中同样的方式被ASP.NET继承和运用。当然，它还有许多附加的增强组件。


身份验证

对于身份验证，ASP.NET支持列表5中的不同选项。

列表5. ASP .NET 身份验证的选项

类型
描述

Windows
　ASP .NET用Windows 身份验证.  
Forms
　基于Cookie,自定义登录表.  
Passport
　微软对外提供Passport 服务.  
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.NET，这里的许多建议对您的ASP代码也是有帮助的。


使用Option Explicit

这是个很好的建议，但并不是每个人都使用它. 当在ASP中使用Option Explicit来强制变量声明时, 您会至少清楚地了解所有内容在哪里定义，及变量如何定义。一旦转到ASP.NET, 我建议您使用Option Strict. Option Explicit 在Visual Basic.NET中是默认的。 但是，如果使用更具强制性的Option Strict, 您就能确保所有的变量都被声明为正确的数据类型. 虽然这势必增添额外工作量，但是长远看来，您将会发现这是很值得的。


避免使用默认属性

正如我们所讨论的，默认的属性将不再被允许。访问属性原本就不是很困难的事。这会使您的代码更具可读性，同时，将来移植时也会更节省时间.


使用括号 和Call关键字

就如本文前面所描述的一样，应尽可能的使用括号和Call 语句。 在 ASP .NET 中您将会被迫使用括号。现在就使用Call语句助您早日养成优良编程习惯，以更好的适应将来的需求。  


避免嵌套式包含文件

这点说来容易，做起来难。但是，您应该尽可能地避免嵌套您的包含文件。说得更清楚一点就是， 您应当最大幅度避免重复嵌套文件。久而久之，往往发生的情况是，您的代码不得不依赖于一个全局变量，而该变量又是在其他地方的包含文件中被定义。您能够访问它是因为您的某个包含文件包含了这个您正真需要的包含文件。

当您转向ASP .NET,您将很有可能将您的全局变量和程序移入类库中。这时如果您了解在哪里访问所有内容，就会方便很多。最后您也许不得不重新放置些文件，并改变一些重名例程的名字。


将功能函数组织成单个文件

在移植过程中的一个策略就是把功能函数和代码转移到Visual Basic 或C#类库中。相对于多重解释型的ASP文件，您最终可以把所有的代码放进它所属的对象。提前组织您的代码会节省您未来的时间。在最理想的状态下，您应该可以将子程序编组为逻辑文件。这样您就能够非常容易地创建一组VB或者C#类。这些功能在COM 对象中恐怕早就该有了。

如果在服务器端的包含文件中您有很多混合的全局变量或常数，不妨将他们也放到一个文件中。一旦您转向ASP.NET,您将能很容易的创建一个能容纳您所有全局变量或常数的类。这样您会有一个更有条理，更容易维护的系统。


尽可能地从内容中移掉代码

您应尽可能的将您的代码从HTML的内容中分离开来，这是另一个易说难做的工作。把混有代码和脚本的函数体清除出函数。这样做的话，您就会跟好的实现代码隐藏，因为这是一个ASP.NET下的理想模式。


请勿在<%%>块中声明函数

在ASP.NET中，这种写法已经不支持了。您应该把您的函数声明在<script>块内。请参考前面结构变化部分中的例子。


避免输出(Render) 函数

与先前讨论的一样，您应该避免使用输出函数。如果现在您能改变或准备您的代码，当组建这些类型的函数时，您应该使用”Response.Write”语句块。


明确地释放资源 （调用Close方法）

请尽量明确地调用任何Close()或您所用对象与资源的释放方法。就释放而言，我们都知道Visual Basic 与VBScript会自动释放资源。它们一般都能立刻释放资源，但是，当我们转向.NET，我们没法确切地知道资源何时被释放。所以您应该尽可能显示地释放资源。


避免混合语言

如果有可能的话，您应该避免在同一页上混合服务器端的VBScript 与Jscript。总的来说，混合不同语言的做法本来就是很糟糕的编程习惯。由于新的编译模式的变化，每页要求在<%%>块内只能有一种语言。这也是一个向ASP.NET 移植时要注意的问题。您可以继续使用你习惯的方式编写客户端脚本。


总结
综上所述，在您把您的应用程序迁至ASP.NET时，您需要注意相当多的方面。我在本文中提出的大多变化应该都是很容易实施的。
如果您的网站很大，当您完成这一过程时，您发现并修复的死代码，低效程序，bug的数量，可能会多得足以让您惊叹。同时，您将能充分享受ASP.NET 乃至整个.NET平台所带来的众多强大功能。