剑三龙渊泽在哪:ASP.NET移植须知（续）

ASP.NET移植须知（续）育龙网 WWW.CHINA-B.C0M 2009年06月08日 来源：互联网育龙网核心提示： ‘ASPSyntaxSetConn=Server.CreateObjectConn.OpenSetRS=Conn.ExecuteResponse.WriteRS‘ASP.NETSyntaxConn=Server.CreateObjectCo
‘ASPSyntax
SetConn=Server.CreateObject
Conn.Open
SetRS=Conn.Execute
Response.WriteRS

‘ASP.NETSyntax
Conn=Server.CreateObject
Conn.Open
RS=Conn.Execute
Response.Write.Value)


数据类型的变化

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

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


结构化的例外处理

虽然在VisualBasic.NET中，仍然沿用熟悉的OnErrorResumeNext及OnErrorGoto错误处理方法，但是，它们不再是最好的方法。VisualBasic现在有成熟的，系统的例外处理方法。它们使用Try，Catch，及Finally等关键字。如果有可能的话，您应该转向这种新的错误处理模式，因为它运用了一个性能更加完善，稳定的机制来处理应用程序错误。

与前面介绍的.NET框架与ASP.NET相比，COM基本没有变化。但是，这并不是说您从ASP.NET上运用它们时，您完全不需要顾及COM对象及它们的行为。以下是几点您必须注意的要素：


线程模式变化

ASP.NET线程模式是MultipleThreadedApartment.这就是说，您所用的为SingleThreadedApartment而生成的组件，在ASP.NET中，如不采取特别预防措施，不再会可靠工作。这包括，但不局限于，用VisualBasic6.0及先前版本生成的所有COM组件。


ASPCOMPAT属性

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

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

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


预先绑定与滞后绑定

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

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

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

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


OnStartPage和OnEndPage方法

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

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


COM小结

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

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

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

CustomSTA
使用ASPCOMPAT属性，和预先绑定
CustomMTA
使用预先绑定，不当但不要用ASPCOMPAT属性
内置对象
使用ASPCOMPAT属性，和预先绑定
OnStartPage，OnEndPage
使用ASPCOMPAT属性，和Server.CreateObject

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

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

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

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

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

项目
描述


定制应用程序配置

设定ASP.NET应用程序对的支持

设定页面相关的配置

设置ASP.NET在IIS系统中的模式

指定一些会话状态选项

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

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


可用的状态管理方法

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

您可以用Web.Config文件中的部分来配置状态管理选项。见下例:
mode="Inproc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="datasource=127.0.0.1;userid=sa;password="cookieless="false"
timeout="20"
/>

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

表4.会话状态存储

选项
描述

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

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


存储COM组件

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

性能

提到性能，当然没有免费可言。可