更新：2007 年 11 月
ASP.NET 早期版本中使用的许多编程概念在 ASP.NET 2.0 版中依然未变，因此对于 ASP.NET 1.x 的用户来说，在 ASP.NET 2.0 中开发应用程序并不会感到陌生。ASP.NET 2.0 与 ASP.NET 1.x 应用程序所运行的操作系统和硬件相同，其中包括 Microsoft Windows 2000 和 Microsoft Internet 信息服务 (IIS) 5.0、Microsoft Windows XP 和 IIS 5.1，以及 Microsoft Windows Server 2003 和 IIS 6.0。
如果打算将现有的 Web 应用程序迁移到 ASP.NET，应该在迁移之前了解 ASP.NET 2.0 的新功能。最重要的更改包括页的代码隐藏模型、Web 应用程序文件夹结构和页的编译模型。
在迁移之前，应确保您的 ASP.NET 1.x 应用程序能够在开发它的 .NET Framework 版本上编译和运行。此外，在开始迁移之前，还应确保 Microsoft .NET Framework 2.0 版已安装并正常运行。
本主题讨论在迁移之前应考虑到的一般注意事项。本主题讨论以下几个部分：
迁移的好处
页模型
跨 ASP.NET 版本共享数据
跨 ASP.NET 版本的 Forms 身份验证
名称冲突
标记符合性
HttpOnly 和跨站点脚本
迁移的好处
将 Web 应用程序迁移到 ASP.NET 2.0 具有许多好处，包括改进的标记和代码分离、保留应用程序文件夹和自动代码编译。
基于分部类的新的代码隐藏模型允许标记和代码更大程度的分离，并且不必在代码隐藏文件中进行控件声明和编写事件连接代码。在 ASP.NET 页的编译模型中，代码隐藏文件在第一次请求对应的 .aspx 文件时在运行时被编译为多个程序集。
现在，ASP.NET 使用一种基于保留文件夹的改进的 Web 应用程序结构。这些文件夹包含特定的内容以帮助您更有效地组织应用程序。有些保留文件夹（例如 App_Data）在响应 Web 请求时并不提供其内容，但是可以从应用程序代码中访问这些文件夹。有关更多信息，请参见 ASP.NET 网站结构。
当对网站上的资源发出请求时，ASP.NET 2.0 编译器自动编译应用程序代码和依赖资源。例如，在 ASP.NET 2.0 中对现有网页或从属资源的更改可以简单地保存下来，只有在该页再次被请求时，该页及其资源才会重新编译。这适用于 App_Code 文件夹中的代码文件、App_GlobalResources 和 App_LocalResources 文件夹中的资源文件和 App_Themes 文件夹中的主题之类的资源。有关页编译模型的更多信息，请参见 ASP.NET 编译概述。
如果要迁移大型应用程序，建议您使用 Visual Web Developer 2005、Visual Web Developer 2005 速成版、Visual Studio 2005 或 Visual Studio 2005 Team System，它们都带有一个迁移向导，可自动执行典型迁移中涉及的很多任务。该向导会做出必要的更改以将 ASP.NET 1.x Web 应用程序转换到 ASP.NET 2.0。
迁移 Web 应用程序并不是必需的，因为 ASP.NET 2.0 可提供与早期版本的高度向后兼容性。如果不迁移，只要应用程序使用 .NET Framework 2.0，就仍然可以在 Web 应用程序中使用 ASP.NET 2.0 的许多功能。若要配置现有 Web 应用程序使用 .NET Framework 2.0，请参见如何：在 .NET Framework 2.0 中运行 ASP.NET 1.x 应用程序。
页模型
ASP.NET 代码隐藏网页模型允许将网页的标记存储在一个文件（.aspx 文件）中，而将编程代码存储在另一个文件（代码隐藏文件）中。ASP.NET 2.0 的代码隐藏模型不同于早期版本，它使用一种称为分部类的新语言功能。与 ASP.NET 的早期版本相比，ASP.NET 2.0 中的新代码隐藏模型允许在更大程度上分离标记和代码。
使用基于 @ Page 指令的 CodeBehind 属性的旧代码隐藏模型的网页仍然可以在 ASP.NET 2.0 中工作。但是，建议将这些页迁移到新代码隐藏模型（使用 @ Page 指令的 CodeFile 属性并在代码隐藏文件中使用分部类定义），以利用改进的标记和代码分离以及自动的页编译。使用旧的代码隐藏模型的网页必须手动进行编译。
可以如如何：将使用 CodeBehind 属性的 ASP.NET 1.1 网页迁移到 ASP.NET 2.0 中所述手动进行更改，也可以使用带有迁移向导的 Microsoft Visual Studio 2005 版本之一，例如 Visual Web Developer 2005 速成版。
ASP.NET 1.1 版还支持代码隐藏模型的一种变体，其中 @ Page 指令的 CodeBehind 属性被 Src 属性所替代。使用 Src 属性的网页仍然可以在 ASP.NET 2.0 中工作，不需要修改即可运行。
作为代码隐藏模型的替代选择，单文件页模型将页的标记和编程代码放在同一个物理 .aspx 文件中。来自 ASP.NET 早期版本的单文件页在 ASP.NET 2.0 中仍继续有效，无需修改即可运行。
跨 ASP.NET 版本共享数据
可以选择将网站的某些部分迁移到 ASP.NET 2.0，同时将其他部分保留不变。如果将网站划分为通过协作提供网站功能的多个独立 Web 应用程序，则可以确定迁移某些应用程序而不迁移其他应用程序。在这种方案中，您将无法在迁移的应用程序和非迁移的应用程序之间共享应用程序状态。会话状态同样也不会在应用程序之间共享，除非提供一个能够同时从 ASP.NET 1.x 和 ASP.NET 2.0 页访问的自定义会话状态解决方案。有关更多信息，请参见实现会话状态存储提供程序。
跨 ASP.NET 版本的 Forms 身份验证
Forms 身份验证提供了一种方法，使您可以使用自己的代码对用户进行身份验证，然后将身份验证标记保留在 cookie 或页的 URL 中。可以使 ASP.NET Forms 身份验证跨运行不同 ASP.NET 版本的应用程序工作，以便一个版本颁发的身份验证票证可由另一个版本使用。
配置身份验证跨 ASP.NET 版本工作类似于跨 Web 服务器网络（网络场）配置身份验证的过程。这两种情况都为共享具有相同密钥的身份验证票证的应用程序显式设置 machineKey 元素的 validationKey 和 decryptionKey 属性。若要支持跨 ASP.NET 版本的身份验证，必须额外进行配置更改，即在 ASP.NET 2.0 应用程序的 Web.config 文件中将 machineKey 元素的 decryption 属性设置为 3DES。ASP.NET 2.0 的默认加密算法是 AES，而 ASP.NET 的早期版本则使用 3DES。有关更多信息，请参见 ASP.NET Forms 身份验证概述。
名称冲突
在迁移之前，建议扫描 Web 应用程序并查找与 .NET Framework 2.0 中的功能类和命名空间冲突的名称。如果 Web 应用程序中使用了在 .NET Framework 中已经使用的缓存、成员资格、配置文件和角色等公共名称，则可能发生冲突。若要避免命名冲突，请找出代码中对引起冲突的名称的引用，并使用完全限定的引用。
ASP.NET 2.0 使用的网站布局不同于早期版本。为了更易于使用 Web 应用程序，ASP.NET 保留了某些可用于特定类型的内容的文件夹和文件名称。保留文件夹中的内容不提供给对针对它的 Web 请求；这可能在现有应用程序中导致问题。因此，在迁移各个应用程序文件之前，建议更改与 ASP.NET 2.0 保留文件夹和文件名称冲突的任何应用程序文件夹或文件的名称。有关 ASP.NET 网站布局中的保留文件夹的更多信息，请参见 ASP.NET 网站布局。
标记符合性
现在，默认情况下 ASP.NET 生成的所有标记和 ASP.NET 中包括的 Web 服务器控件都符合 XHTML 1.0 Transitional 标准。这可能在迁移之后导致意外的 HTML 呈现问题。为了帮助 Web 应用程序的迁移，可以在 Web.config 文件中将 xhtmlConformance 元素的 mode 属性设置为 Legacy。这应该是迁移过程中的一个临时步骤。从长远考虑，建议在将 xhtmlConformance 元素的 mode 属性设置为 Transitional 的情况下运行应用程序。此外，建议将 DOCTYPE 元素添加到迁移后的页。有关使网页符合 XHTML 标准的好处的更多信息，请参见 ASP.NET 和 XHTML。
HttpOnly 和跨站点脚本
在 .NET Framework 2.0 中，HttpCookie 类的 HttpOnly 属性是新增的。将此属性设置为 true 有助于缓解跨站点的脚本威胁。对于 Forms 身份验证 cookie 和会话 ID cookie，其 HttpOnly 属性将自动设置为 true，以使客户端脚本无法使用这些 cookie。如果迁移后的网页引发 NullReferenceException 异常，则可能指示由于将 HttpOnly 属性设置为 true 而导致来自客户端的会话丢失。如果是这样，您可以使用下列解决方案之一：
在 Global.asax 文件中的 HttpApplication 类的 EndRequest 事件处理程序中，将每个 cookie 的 HttpOnly 属性设置为 false。
编写一个自定义模块，此模块可将该 cookie 复制到其他 cookie 中并清除 HttpOnly 属性，这样客户端脚本就可以对该 cookie 进行操作。
编写一个自定义会话 ID 管理器，且不要将 HttpOnly 属性设置为 true。
有关跨站点脚本威胁缓解的更多信息，请参见“Mitigating Cross-site Scripting with HTTP-only Cookies”（利用仅限 HTTP 的 Cookie 缓解跨站点脚本威胁）。