您现在的位置： 
移植方法的选择
将站点移植到Visual Basic .NET和.NET框架的第一步是看看有哪些方法可供选择。现在有三种方法可以使用：
? 将站点和Visual Basic 6.0的组件移植到ASP .NET和Visual Basic .NET
? 将站点移植到ASP .NET，再用COM+ interoperability与现存的Visual Basic 6.0组件通讯
? 不改变现存的站点，而通过增加用ASP .NET和Visual Basic .NET写的新的功能模块来扩展站点的功能
在开始开发之前，开发小组确定了利用.NET的哪些功能模块来替代网站中复杂的，且有时会有问题的代码，并增加一些新的功能。具体的讲，他们希望按下面的要求重建网站：
? 用ASP .NET认证来替代原来的用户安全机制
? 用ASP .NET Web Form确认控件来替代客户端用于报告产品漏洞和描述缺点的确认逻辑
? 用ASP .NET Web Services将Microsoft其它的网站溶入beta版产品漏洞报告体系中
? 利用.NET框架的本地化功能建造一个可以很容易实现本地化的Web站点
? 利用ASP .NET向用户提供个性化的菜单和横幅图片
为了充分利用这些特点，开发组决定将ASP页面移植成ASP .NET页面。他们将不移植现存的Visual Basic 6.0的ActiveX组件，而是创建新的Visual Basic .NET组件来实现Web Service和本地化。
现在让我们看看为了完成移植，对这个网站到底做了哪些修改。
结合ASP .NET认证功能
移植的第一步就是用ASP .NET中基于cookie的认证机制来替换原来的客户安全机制。这种安全认证机制首先出现在PDC技术预览中，并在Visual Studio .NET Beta 1中得到了发展。它的目标是确定谁在访问网站，而不是阻止用户访问。因此，开发组修改了成员资格系统，帮助用户注册到Web站点，并且在以后的Beta版产品中可以继续使用。
识别每个访问者的目的是跟踪他们报告的漏洞和缺点，并与他们进行必要的交流，以彻底解决问题。除了把用户的反馈送到特定的测试站点，用户还可以定制这个站点，以满足自己的需要，帮助客户将注意力集中在他们需要的信息上。把用户和他们感兴趣的内容联系起来能帮助站点管理员了解用户对什么问题最感兴趣。大多数测试站点包括了Visual Studio .NET和.NET框架各个方面的内容，允许用户访问站点上所有的文档，但某些用于特定方面（比如Visual Studio .NET IDE shell整和）的测试站点利用过滤器向客户只提供他们感兴趣的文档。
原先使用的认证方式使用一个ASP服务器端文件和一个Visual Basic组件所提供的方法，验证来访者所提供的用户ID和密码是否是数据库的成员。这个文件提供了可重用代码来完成安全检查，但这就意味着这个文件需要被包含在每一页的开头，才能保证这一页不会被未经过认证的用户打开。在每一页包含这个文件给管理员配置不需要安全保护的页带来了麻烦。
在ASP .NET中实现认证是很容易的，因为基于cookie的认证通过将站点的文档存放在某一个特定的文件夹实现了对文档的保护。当用户企图访问这个受保护的文档时，.NET框架将自动判断用户是否经过了认证。如果用户未被认证，.NET框架会把这个未经认证的请求重定向到某一个特定的HTML表单，让用户输入认证信息，并提交这个表单。如果用户得到了认证，.NET框架会产生一个可以辨别用户的cookie，并重定向到原先的请求页面。.NET框架还提供了一些类来帮助我们与认证过程交互和访问保存在cookie中的认证信息。
我们可以用Web站点的config.web文件来配置ASP .NET的认证体系。这个配置文件包含了一个用于指定认证方式的块、该块指明了HTML登陆表单的URL和密码的格式。图3是一个设置基于cookie的认证的config.web文件。
Web站点上原来的那种安全认证方式为每一个访问者唯一确立了一个对话ID。因为已经生成了这个ID，所以我们在移植认证过程不要改动现存的代码。ASP .NET认证机制将把未经认证的用户重定向到登陆页，让用户提交信用证。一旦提交了登陆页，用户ID和密码将被确认，还将产生一个会话ID。
实现ASP .NET认证体系只要修改原来的登陆页面的两个地方。我们没有向客户的cookie写入会话的关键字，而是使用了ASP .NET认证cookie，将它的值设为会话的关键字。然后通过CookieAuthentication 类的RedirectFromLoginPage方法将用户重新引导到原先的请求页。在接下来的请求中，将通过.NET框架的HttpContext.User类来访问会话ID。图4显示的是修改后的登录认证检查。
除了提供了一种更安全、更容易实现的安全认证体制外，ASP .NET认证体制还可以区别对待认证过的和未经认证的内容。因为保护的范围是由config.web文件中的目录结构决定的，所以只要把内容移出受保护的文件夹就可以取消对内容的保护了。
为了让认证机制能发挥作用，所有需要认证才可以访问的文件的扩展名应改为.aspx（ASP.NET文件的扩展名）。正如你将在下面看到的，这是一个相对简单的过程。
将站点移植到Visual Basic .NET和.NET框架的第一步是看看有哪些方法可供选择。现在有三种方法可以使用：
? 将站点和Visual Basic 6.0的组件移植到ASP .NET和Visual Basic .NET
? 将站点移植到ASP .NET，再用COM+ interoperability与现存的Visual Basic 6.0组件通讯
? 不改变现存的站点，而通过增加用ASP .NET和Visual Basic .NET写的新的功能模块来扩展站点的功能
在开始开发之前，开发小组确定了利用.NET的哪些功能模块来替代网站中复杂的，且有时会有问题的代码，并增加一些新的功能。具体的讲，他们希望按下面的要求重建网站：
? 用ASP .NET认证来替代原来的用户安全机制
? 用ASP .NET Web Form确认控件来替代客户端用于报告产品漏洞和描述缺点的确认逻辑
? 用ASP .NET Web Services将Microsoft其它的网站溶入beta版产品漏洞报告体系中
? 利用.NET框架的本地化功能建造一个可以很容易实现本地化的Web站点
? 利用ASP .NET向用户提供个性化的菜单和横幅图片
为了充分利用这些特点，开发组决定将ASP页面移植成ASP .NET页面。他们将不移植现存的Visual Basic 6.0的ActiveX组件，而是创建新的Visual Basic .NET组件来实现Web Service和本地化。
现在让我们看看为了完成移植，对这个网站到底做了哪些修改。
结合ASP .NET认证功能
移植的第一步就是用ASP .NET中基于cookie的认证机制来替换原来的客户安全机制。这种安全认证机制首先出现在PDC技术预览中，并在Visual Studio .NET Beta 1中得到了发展。它的目标是确定谁在访问网站，而不是阻止用户访问。因此，开发组修改了成员资格系统，帮助用户注册到Web站点，并且在以后的Beta版产品中可以继续使用。
识别每个访问者的目的是跟踪他们报告的漏洞和缺点，并与他们进行必要的交流，以彻底解决问题。除了把用户的反馈送到特定的测试站点，用户还可以定制这个站点，以满足自己的需要，帮助客户将注意力集中在他们需要的信息上。把用户和他们感兴趣的内容联系起来能帮助站点管理员了解用户对什么问题最感兴趣。大多数测试站点包括了Visual Studio .NET和.NET框架各个方面的内容，允许用户访问站点上所有的文档，但某些用于特定方面（比如Visual Studio .NET IDE shell整和）的测试站点利用过滤器向客户只提供他们感兴趣的文档。
原先使用的认证方式使用一个ASP服务器端文件和一个Visual Basic组件所提供的方法，验证来访者所提供的用户ID和密码是否是数据库的成员。这个文件提供了可重用代码来完成安全检查，但这就意味着这个文件需要被包含在每一页的开头，才能保证这一页不会被未经过认证的用户打开。在每一页包含这个文件给管理员配置不需要安全保护的页带来了麻烦。
在ASP .NET中实现认证是很容易的，因为基于cookie的认证通过将站点的文档存放在某一个特定的文件夹实现了对文档的保护。当用户企图访问这个受保护的文档时，.NET框架将自动判断用户是否经过了认证。如果用户未被认证，.NET框架会把这个未经认证的请求重定向到某一个特定的HTML表单，让用户输入认证信息，并提交这个表单。如果用户得到了认证，.NET框架会产生一个可以辨别用户的cookie，并重定向到原先的请求页面。.NET框架还提供了一些类来帮助我们与认证过程交互和访问保存在cookie中的认证信息。
我们可以用Web站点的config.web文件来配置ASP .NET的认证体系。这个配置文件包含了一个用于指定认证方式的块、该块指明了HTML登陆表单的URL和密码的格式。图3是一个设置基于cookie的认证的config.web文件。
Web站点上原来的那种安全认证方式为每一个访问者唯一确立了一个对话ID。因为已经生成了这个ID，所以我们在移植认证过程不要改动现存的代码。ASP .NET认证机制将把未经认证的用户重定向到登陆页，让用户提交信用证。一旦提交了登陆页，用户ID和密码将被确认，还将产生一个会话ID。
实现ASP .NET认证体系只要修改原来的登陆页面的两个地方。我们没有向客户的cookie写入会话的关键字，而是使用了ASP .NET认证cookie，将它的值设为会话的关键字。然后通过CookieAuthentication 类的RedirectFromLoginPage方法将用户重新引导到原先的请求页。在接下来的请求中，将通过.NET框架的HttpContext.User类来访问会话ID。图4显示的是修改后的登录认证检查。
除了提供了一种更安全、更容易实现的安全认证体制外，ASP .NET认证体制还可以区别对待认证过的和未经认证的内容。因为保护的范围是由config.web文件中的目录结构决定的，所以只要把内容移出受保护的文件夹就可以取消对内容的保护了。
为了让认证机制能发挥作用，所有需要认证才可以访问的文件的扩展名应改为.aspx（ASP.NET文件的扩展名）。正如你将在下面看到的，这是一个相对简单的过程。
