'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&