常见的 Web 项目转换问题及解决方案

ASP.NET 和 Visual Studio 是什么？

ASP.NET 是一种创建动态 Web 应用程序的技术。编译 ASP.NET 页（Web 窗体），因此可以生成功能强大、基于窗体的 Web 页。生成这些页时，可以使用 ASP.NET 用户控件创建常见的 UI 元素，并对它们进行常规任务的编程。

Visual Studio 是一个集成开发环境 (IDE)，开发人员可以使用它通过众多编程语言（包括 C# 和 Visual Basic）中的一种来创建用于 .NET Framework 的程序。

您将发现，转换 Web 应用程序以使用 Visual Studio 2005 和 ASP.NET 2.0 的新增功能可以简化开发工作，并为编译和部署代码提供了更多的选择。

Web 项目更改

这些更改影响开发、配置和部署 Web 应用程序的方式。作为开发人员或 Web 站点管理员，您需要了解这些更改以便正确地生成、部署和维护 Web 应用程序。

没有项目文件。Visual Studio 2005 不再使用项目文件来明确地列出 Web 项目中的文件。相反，它将所有文件和文件夹作为 Web 项目的一部分。以前存储在项目文件中的项目信息现在保存在解决方案或 Web.config 文件中。

特殊目录。一个 ASP.NET 1.x 应用程序有一个必需的文件夹 (\bin)，用于保存程序集。ASP.NET 2.0 应用程序具有一个较大的、已定义的文件夹结构。新目录以前缀“App_”开头，用于存储资源、程序集、源代码以及其他组件。新的文件夹结构不再需要项目文件，并且部署时能支持一些新选项。

代码隐藏模型。在 ASP.NET 1.x 中，代码隐藏模型能够将内容（例如，foo.aspx）从代码（例如，foo.aspx.vb）中分离出来。内容页从代码隐藏页继承，代码隐藏页包含由用户和设计器生成的代码。
通过部分类（允许一个类跨越多个文件），ASP.NET 2.0 增强了代码隐藏模型。在新的代码隐藏模型中，内容页从一个经过编译的类继承，这个经过编译的类包括相应的代码隐藏页和一个自动生成的部分类，部分类定义了内容页中所用控件的字段声明。这一更改让自动生成的代码从用户代码中分离出来，并使代码隐藏页变得更小、更简洁。部分类结构还降低了由编辑设计器生成的代码在无意中破坏页面的风险。

编译模型（一个程序集到多个程序集）。在 Visual Studio®.NET 2003 中，所有代码隐藏类文件和支持代码都预编译到一个有固定名称的单独程序集中。在 Visual Studio 2005 中，用唯一生成的文件名动态（默认）创建多个程序集。例如，默认行为是将文件夹中的所有 Web 窗体和用户控件都编译到它们自己的程序集中。App_Code 文件夹中的公共源代码将自动编译到它自己的程序集中。这个新的编译模型引发了 Web 应用程序结构中的一些更改，但极大地增强了部署选项以及 Web 应用程序如何在 Web 服务器上发挥作用。

部署选项（预编译、全编译、可更新的站点等）。在 Visual Studio 以前的版本中，对 Web 应用程序进行预编译并将它作为一个大型程序集部署。内容页（例如，*.aspx 或 *.ascx）在服务器上不进行编译并且不能编辑。使用 Visual Studio 2005 中新增的页编译模型和文件夹结构，则可以在许多不同的配置中部署 Web 应用程序。在一种极端情况下，您可以预编译所有的内容页、它们的代码隐藏类文件及其隐藏的类设计器页，然后部署一个包含完全编译的程序集的 Web 应用程序。在这种模式中，不能在服务器上轻易更改应用程序。另一种极端情况是，您可以部署一个根本没有进行预编译的应用程序。在该配置中，您可以在服务器上直接更改应用程序中的内容页、代码隐藏类文件或任意其他代码。当用户请求服务器上的页时，这些页将动态编译。

这些操作更改中的每一项可能都需要您在转换 Web 应用程序之前或之后，对应用程序的体系结构和部署过程进行修改。

转换 Web 项目

转换 Web 项目不仅仅需要更改框架版本！转换包括三个部分：

转换前 — 在运行转换向导之前，查看并有可能修改 Web 项目的体系结构。

转换 — 运行 Visual Studio 2005 转换向导以转换 Web 项目。

转换后 — 解决转换向导没有发现或者无法解决的任何问题。

对于第 1 部分和第 2 部分，您应该阅读并应用将 Web 项目转换到 Visual Studio 2005 的分步指南中列出的步骤。

对于第 3 部分，您应该应用本白皮书中列出的解决方案。

转换向导

Visual Studio 2005 有一个内置的转换向导，用来帮助您转换 Web 应用程序。该向导自动完成将应用程序转换为使用 ASP.NET 2.0 功能所必需的许多基本步骤。

运行向导

只要您在 Visual Studio 2005 中打开一个Visual Studio .NET 2003 Web 项目，就会自动调用该向导。该向导检测应用程序文件夹中是否存在 Web 项目文件（例如 *.vbproj 或 *.csproj），然后自动开始转换过程。

转换完成

转换完成后，应该查看转换报告以了解是否必须执行任何其他手动步骤来完成转换。

转换报告

转换向导将在 XML 文件和文本文件中记录对 Web 项目所做的更改。转换向导完成后，它会显示 XML 版本的报告。该报告将向您显示向导遇到的所有问题以及代码区域，您可能需要在代码区域采取其他步骤才能完成向导。

该报告分成两部分，一部分是转换的解决方案，另一部分是一个或多个项目。解决方案报告几乎都是没有错误的。然而，项目部分会针对项目中的每个文件列出多个问题。您应该查看该部分，然后解决转换向导报告的所有问题。

如果您关闭了转换报告，可能会发现始终有一个文本版本位于转换的项目的顶部。

注 在 Visual Studio 2005 的最新版本中，文本报告的名称为 ConversionReport.txt。以后的版本将把此文件重命名为 ConversionReport.Webinfo。在 Web 应用程序的根文件夹中可以找到文本版本。

通知类型

报告中的每一项都属于以下三个类别之一：

注释 — 通知您向导采取的操作。您将看到许多关于已删除或移动的文件以及已删除或注释掉的代码的注释。注释只在转换报告的文本版本中列出，在 XML 版本中省略。

警告 — 每当向导不得不采取可能会在应用程序中导致行为更改或可能的编译错误的行动时，就会产生警告。警告是想要查看的项，但是可能不需要对其采取行动。

错误 — 如果向导遇到无法自动转换的内容，就会产生错误项。这些项需要进行特别处理才能完成转换。通常，错误是您尝试运行应用程序时会产生编译错误的东西。

第 2 部分：常见的转换问题

虽然 Visual Studio 2005 旨在与使用 Visual Studio®.NET 2003 开发的代码一起工作，但是您可能会遇到一个或多个常见的转换问题。本节，我们将了解一些最常见的问题。

注 转换向导在 Visual Studio 2005 的最新版本中已经升级，并且可以自动检测和修复以下一些问题。然而，如果该向导遗漏了特定的问题，您可以手动应用下面描述的解决方案来完成 Web 项目的转换。

问题 1 ：代码隐藏类文件 (CB-CB) 引用

注 CB 是 Web 窗体 (*.aspx) 或用户控件 (*.ascx) 的代码隐藏文件的缩写。

新的编译模型使用多个通常在服务器上动态编译的程序集。该模型改善了 Web 站点的性能和可更新性。

然而，如果您的代码隐藏文件引用其他的代码隐藏文件，那么您将有一个中断的引用，这是因为引用的代码隐藏文件将不再位于同一个程序集中。

以下是一些可能引发此问题的常见方式：

使用 Web 窗体或用户控件作为另一个 Web 窗体或用户控件的基类。

使用 LoadControl() 并将结果转换为另一个用户控件，例如
UserControl1 c1 = (UserControl1)LoadControl("~/UserControl1.ascx");

创建一个 Web 窗体类实例，例如
WebForm1 w1 = new WebForm1();
，其中 WebForm1 是在 Web 窗体的代码隐藏文件中定义的一个类。

如何修复

要解决此问题，需要更改应用程序以便找到该引用。因为这是一个 CB-CB 引用，所以解决问题的最简单方法是添加对进行该引用的 Web 窗体或用户控件的引用指令。这将通知编译器要链接到哪个程序集。

我们假设出现以下情况：

文件	ASP.NET 1.x 代码
Page1.ascx	-
Page1.ascx.cs	Control1 c = (Control1)LoadControl("~/Control1.ascx");

将代码更改为使用引用指令：

文件	ASP.NET 2.0 代码
Page1.ascx	<%@ Reference Control="~/Control1.ascx" %>
Page1.ascx.cs	Control1 c = (Control1)LoadControl("~/Control1.ascx");

通过使用引用指令，明确地通知编译器在哪里寻找您要使用的 Web 窗体或控件。请注意，在 Visual Studio 2005 的最新版本中，转换向导将自动执行此操作。

问题 2 ：独立类文件 (SA - CB) 引用

注 SA 是独立类文件的缩写。

如果您有一个引用代码隐藏类文件中代码的独立类文件，则可能会遇到另一种中断的引用。这与中断的 CB-CB 引用类似，除了在 App_Code 文件夹中有一个独立类文件，该文件试图引用一个单独的页程序集。引发此问题的一个常见方式是访问 CB 类中的一个类变量。

如何修复

修复一个中断的 SA-CB 引用涉及的更多。由于该问题出现在 SA 文件中，因此不能使用引用指令来找到该引用。而且在转换后，SA 文件移动到 App_Code 文件夹，因此该类文件将无权在编译时访问 App_Code 程序集。

解决方案是在编译时引用的 App_Code 文件夹中创建一个抽象的基类，该基类将在运行时从页程序集中加载实际的类。

我们假设出现以下情况：

文件	ASP.NET 1.x 代码
Control1.ascx	inherits="Control1"
Control1.ascx.cs	class Control1 : System.Web.UI.UserControl { public static string myName = "Control1"; public void foo() { some code } }
Code1.cs	String myName = "Class1 + " + Control1.myName;

更改代码以使用抽象基类：

文件	ASP.NET 2.0 代码
Control1.ascx	inherits="migrated_Control1"
Control1.ascx.cs	class migrated_Control1 : Control1 { override public void foo() { some code } }
App_Code\Code1.cs	String myName = "Class1 + " + Control1.myName;
App_Code\Stub_Control1.cs	abstract class Control1 : System.Web.UI.UserControl { public static string myName = "Control1"; abstract public void foo(); }

由于抽象基类现在位于 App_Code 文件夹中，因此允许独立类文件和 CB 文件在编译期间找到一个类（本例中名为 Control1）。然而，独立类文件将在运行时使用后绑定加载原始类（在本例中，重命名为 migrated_control）。注意：在 Visual Studio 2005 的最新版本中，转换向导将自动创建此代码。

问题 3 ：循环引用

如果代码隐藏文件引用其他代码隐藏

文件，这个被引用的代码隐藏文件又引用原始文件，就会发生循环应用。这种情况可能发生在两个或更多代码隐藏文件中，例如：



还会发生在程序集之间，其中一个程序集引用另一个

程序集，引用的程序集又引用原始程序集，例如：



如何修复

第一种循环引用的解决方案是：用其中一个引用在 App_Code 文件夹中创建一个抽象基类，然后从相关联的 Web 窗体或用户控件文件中删除引用指令。这将破坏循环引用。

第二种循环引用是 ASP.NET 编译器由于性能原因而“批处理”程序集的副产品。默认情况下，它将 Web 窗体和用户控件放在一个文件夹中，然后将它们编译成一个程序集。

解决此问题的方式有很多，但是我们建议将引用的页（例如，Pages2.aspx.vb 和 Pages3.aspx.vb）移动到它们自己的文件夹中。

默认情况下，ASP.NET 编译器将创建一个包含这些页的单独的程序集，程序集 A 和 B 之间的循环引用将被删除。



问题 4 ：资源管理器

在 Visual Studio .NET 2003 中，资源管理器用于管理 Web 应用程序中的资源。典型的示例如下所示：

文件	ASP.NET 1.x 代码
Control1.ascx.cs	Assembly a = Assembly.Load("myApp");ResourceManager rm = new ResourceManager("myApp.Resource1", a);String s = rm.GetString("foo");
Resource1.resx	Contains name/value pair "foo = bar"

此类代码有问题，因为它取决于知道要加载的程序集名称，但在 Visual Studio 2005 中该名称不再是一个固定名称。

如何修复

由于 Visual Studio 2005 使用不确定的程序集命名，因此需要将代码更改为使用新的资源模型。最简单的方法是将 Resource1.resx 移到一个名为 App_GlobalResources 的文件夹中。通过强命名，Visual Studio 2005 自动将在该文件夹中找到的所有资源用于 Web 应用程序（利用 IntelliSense 使资源成为可发现的）。下面是转换后的示例：

文件	ASP.NET 2.0 代码
Control1.ascx.cs	String s = Resources.Resource1.foo;
App_GlobalResources\ Resource1.resx	Resource1.resx moved to App_GlobalResources Contains name/value pair "foo = bar"

这只是使用 Visual Studio 2005 中新的资源模型的一种方法，您应该查看该资源模型文档，以发现该模型中的新增功能。

问题 5 ：不再对已排除的文件进行排除

在 Visual Studio .NET 2003 中，必须明确确定是否在 Web 项目中包括文件。如果没有明确列出包含某个文件，则该文件会排除在项目之外。还可以通过将一个代码文件的生成操作设为“none”，来停止生成该代码文件。该信息存储在项目文件中。

转换时必须考虑几个问题，例如：

排除在一个项目之外的文件可能包括在另一个项目中

您是否会因为一个排除的文件可能是用户想要记住的一个代码片段就尝试转换它呢？

在 Visual Studio 2005 的最新版本中，转换向导将原样保留排除的文件并在转换报告中注明。因此，您的 Web 项目将包含额外的、未转换的文件，它们现在是项目的一部分。根据文件的扩展名，编译器可能会尝试编译该文件，这可能会引发应用程序中的冲突。

如何修复

转换之后，可以从项目中删除任何不想要的、以前排除的文件。您也可以使用“Exclude from Project”功能（可以在解决方案资源管理器找到）排除它们，通过使用安全的扩展名“.exclude”对它们进行重命名，以便有效地从 Web 应用程序中删除它们。

注 用“.exclude”扩展名排除的文件仍然是 Web 项目的一部分，但不对它们进行编译，如果它们碰巧在服务器上，IIS/ASP.NET 也不支持这些文件。注 未来版本的转换向导将更主动，并且在它认为安全的情况下将排除文件。

问题 6 ：孤立的 resx 文件

Visual Studio .NET 2003 为 Web 窗体和用户控件生成了一个 resx（资源）文件。通常情况下，用户不使用这些文件，因为它们是自动生成的并且可能会改写用户添加的代码。

转换之后并不删除这些 resx 文件，因为迁移向导不确定用户是否已经添加了需要保存的资源。

如何修复

查看生成的 resx 文件并将用户数据保存到它自己的资源文件中。将该数据合并到一个资源文件中会更好。

根据需要将该资源文件移到特殊的文件夹 App_GlobalResources or App_LocalResources 中，这样 Web 应用程序就可以使用它了。

用这种方式保存用户数据后，从 Web 项目中删除生成的 resx 文件。



问题 7 ：代码隐藏文件中的额外类型

在 Visual Studio®.NET 2003 中，通过在 Web 窗体或用户控件之一的代码隐藏文件中存储类型，有可能在不同页之间共享类型（例如，结构、枚举、接口、模块等）。

该模型在 Visual Studio 2005 中是中断的，因为一个 Web 窗体和多个用户控件编译到它们自己的程序集中，其他类型不再可发现。

如何修复

转换向导完成应用程序转换后，就会将任何非私有的额外类型移到 App_Code 文件夹中它自己的独立代码文件中。由于必须跨程序集工作，因此您可能还需要将访问修饰符更改为 public。通过 Web 应用程序，共享类型将进行自动编译，并且是可发现的。

问题 8 ：访问自动生成的控制变量

在 Visual Studio®.NET 2003 中，代码隐藏的类文件包含用户和自动生成的设计器代码。后者可以包含控制变量声明和页功能。虽然不建议这样做，但是一些开发人员将控制变量的访问权限更改为 Public，这样就可以在它们的类之外对它们进行修改。示例如下所示：

文件	ASP.NET 1.x 代码
UserCtrl1.ascx	<asp:Label id="Label1" runat="server">UC1</asp:Label>
UserCtrl1.ascx.cs	public System.Web.UI.WebControls.Label Label1;
Page1.ascx.cs	UserCtrl1 uc1 = (UserCtrl1)LoadControl("~/UserCtrl1.ascx");uc1.Label1.Text = "Foo";

在 Visual Studio 2005 中，因为是通过部分类将用户和自动生成的设计器代码分开了，所以此更改不起作用。部分类允许一个类跨多个文件，并且用于维护用户和自动生成的代码之间干净的分隔。

如何修复

通常情况下，建议您将代码更改为不依赖于自动生成的代码的更改的访问级别。然而，如果代码中有数百个位置调用诸如自动生成这样的变量并且需要快速运行代码，那么有一个很有用的替代方案。您可以将原始控制变量重命名为其他名称，然后创建一个公有属性来访问重命名的控制变量。例如：

文件	ASP.NET 2.0 代码
UserCtrl1.ascx	<asp:Label id="p_Label1" runat="server">UC1</asp:Label>
UserCtrl1 hidden partial class	// this will be auto-generated in the hidden, partial classprotected System.Web.UI.WebControls.Label p_Label1;
UserCtrl1.ascx.cs	public System.Web.UI.WebControls.Label Label1 { get { return p_Label1; } set { p_Label1 = value; }}
Page1.ascx.cs	UserCtrl1 uc1 = (UserCtrl1)LoadControl("~/UserCtrl1.ascx");uc1.Label1.Text = "Foo";

问题 9 ：无法切换到设计视图

Visual Studio 2005 中内置的新 Visual Web 设计器在正确的 HTML 方面比 Visual Studio .NET 2003 更严格。如果 aspx 页包含不匹配的标记或格式不正确的 HTML，则该设计器将不允许您在 Visual Studio 2005 内切换到设计视图。相反，您将被限制在代码视图，直到修复了问题为止。发生该问题的原因是 Visual Studio 2005 内置有新的源代码保留和验证功能。

如何修复

为了避免此问题，您所能做的就是确保 aspx 页中的标记格式正确。如果在从代码视图切换到设计视图的后转换时遇到问题，则该问题几乎肯定是错误的标记。

问题 10 ：无法解析文件名

您可能会看到有些模糊的错误消息，告诉您无法解析某个文件。这意味着在 HTML 标记上找不到 ‘Codebehind’ 或 ‘Src’ 属性。

如果您的 Web 窗体或用户控件不包含以上任何一个属性，则该向导找不到匹配的代码隐藏文件，也无法转换该页。

如何修复

如果这碰巧是一个纯 HTML 页，则该错误可以忽略，如果应用程序具有使用 aspx 扩展名的 HTML 页，则会经常遇到此错误。

为了避免此问题，请确保为 html 文件正确命名，并且在 HTML 标记上的 Web 窗体和用户控件中使用 ‘Codebehind’ 和 ‘Src’ 属性。

注 在下一个版本的 Web 项目迁移向导中，通过使用以下消息可以使该错误更易于描述。

更多详情请查看：http://msdn2.microsoft.com/zh-cn/library/aa479312.aspx

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1880491