在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 文件设置范例

如果您的应用程序使用了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. 会话状态存储信息

当你选用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 身份验证的选项

除了新的Passport 身份验证选项以外，这些选项在ASP中是相同的。以Windows为基础的身份验证在以下例子中的配置下能得到运用。
<configuration>
<system.web>
<authentication mode="Windows"/>
</system.web>
</configuration>


授权

当您的用户通过身份验证之后，您可以对希望他们访问的资源进行授权。以下例子说明访问权限被授予“jkieley”和“jstegman”，任何其他人都将被拒绝访问。
<authorization>
<allow users="NORTHAMERICAjkieley, REDMONDjstegman"/>
<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平台所带来的众多强大功能。