假定您处于以下情况：
| 原 ASP.NET 1.x 代码 | |
| 文件（位于 WebAppRootFolder 下） | 代码 |
Control1.ascx | inherits="Control1" |
- Control1.ascx.cs | class Control1 :System.Web.UI.Page { |
Code1.cs | Control1 c = (Control1)LoadControl("~/Control1.ascx"); |
更改代码以使用引用指令：
| ASP.NET 2.0 版本 | |
| 文件（位于 WebAppRootFolder 下） | 代码 |
Control1.ascx | inherits="d_Control1" |
- Control1.ascx.cs | class d_Control1 :Control1 { |
App_Code\Code1.cs | Control1 c = (Control1)LoadControl("~/Control1.ascx"); |
App_Code\Stub_Control1.cs | abstract class Control1 :System.Web.UI.Page { |
由于抽象集类现在位于 App_Code 目录下，因此它将允许独立类文件和 CB 文件在编译过程中查找类（在本示例中名为 Control1）。但是，在运行时，独立类文件将使用后期绑定来加载原始类（在本示例中重命名为 d_Control1）。请注意，在 Visual Studio 2005 的最终版本中，转换向导将自动为您创建此代码。
代码分离文件中的附加类型
在 ASP.NET 1.x 中，通过将类型（例如，结构、枚举、界面和模块等）存储在一个用于 Web 窗体或用户控件的代码分离文件中，可以在不同的页面之间共享这些类型。
在 ASP.NET 2.0 中，由于 Web 窗体和用户控件被编译到各自的程序集中，因此此模式被破坏，无法再发现附加类型。
如何修复
当转换向导转换完应用程序之后，只将任一非私有附加类型移到它在 App_Code 目录下专用的独立代码文件中。您还需要将该类型的访问修改符更改为 public，因为该类型必须在多个程序集中工作。共享类型将自动编译，并且可通过 Web 应用程序发现。
请注意，在 Visual Studio 2005 的最终版本中，转换向导将自动执行此操作。生成的独立文件将位于 Migrated 子目录下，该文件的文件名将基于在其中找到附加类型的文件以及所找到的类型的名称。您可以根据需要随意重命名此文件，只需将其保留在 App_Code 目录下即可。
同一位置处的多个 Web 项目
如果在同一解决方案中有多个 Web 项目共享同一个目录位置，则 Visual Studio 2005 将把在该位置找到的所有文件都视为单个 Web 应用程序的一部分。尽管向导会自动将所有程序集引用移到 web.config 文件中，您仍然可能遇到下列问题：
由项目合并导致的命名冲突。 | |
如果一个 Web 项目引用另一个 Web 项目，并且两个项目合并到一起，则会产生引用问题。 |
如何修复
在转换项目之前将它们分隔开，即，将它们放在各自单独的目录位置。
模糊引用和命名冲突
.net Framework 2.0 添加了许多新的命名空间和类。其中一些有可能导致与 ASP.NET 1.x 应用程序的冲突。例如，新的个性化功能引入了名为 Profile、Membership 和 MembershipUser 的类。Profile 名称对于要跟踪用户信息的开发人员来说是特别常用的。因此，如果应用程序中具有 Profile 类，并且您尝试使用任一新增个性化功能，则可能会遇到关于模糊类引用的编译器警告。
如何修复
针对命名冲突进行事先计划是相当困难的。您需要快速浏览新的 ASP.NET 类。如果看到可能会与应用程序中的某些内容冲突的任何名称，则需要考虑使用明确命名。例如，使用 System.Web.Security.Membership 而不导入/使用 System.Web.Security，然后使用 Membership 类。
设计视图问题
visual Studio 2005 中内置的新增 Visual Web Designer 能够比 Visual Studio .NET 2003 得到更加严格的 HTML。如果 .aspx 页面包含不匹配的标记或格式不佳的 HTML，那么设计器将不允许您切换到 Visual Studio 2005 内的设计视图，而只能切换到代码视图
