发布日期： 7/27/2005 | 更新日期： 7/27/2005
开发和部署最佳做法
Microsoft Corporation
本页内容
在 .NET Framework 2.0 中测试使用 .NET Framework 1.1 开发的应用程序
简介Microsoft .NET Framework 2.0 是在 Microsoft .NET Framework 1.0 和 1.1 成功的基础上构建的，用于为 Web 和 Microsoft Windows 客户端应用程序提供最佳的运行库环境。对于 .NET Framework 1.1 应用程序，Microsoft 的兼容性目标是：这些应用程序能够在 .NET Framework 2.0 上顺利运行（除一组记录在案的更改之外）。在 Beta 2 发布期间，我们还没有达到这个目标，并且正在寻找有关这些应用程序问题的反馈，以便在 .NET Framework 2.0 发布之前解决这些问题。本文将探讨应用程序的兼容性方案，并为各个阶段提供最佳做法建议。
执行摘要•
这里提供已知破坏性更改的完整列表。该列表适用于 Beta 2，并将进一步更新以用于 RTM。如果您遇到该列表以外的更改，请发送邮件至 netfxcmp@microsoft.com。
•
Microsoft 建议您在 Beta 2 期间针对 .NET Framework 2.0 测试您的 .NET Framework 1.1 应用程序。兼容性测试方案提供该操作的指导。
•
即使在计算机上安装了 .NET Framework 2.0，使用 .NET Framework 1.1 构建的单机版 Microsoft Windows 客户端或 Web 应用程序也将自动在 1.1 框架上运行。
•
本机应用程序的托管外接程序（例如，Microsoft Office 或 Internet Explorer）将自动在计算机安装的最新版本的 .NET Framework 上运行。在部署该版本的 Framework 之前，开发人员和 IT 经理应该针对 .NET Framework 2.0 测试这些外接程序。
•
现在，我们仍然在寻找更多的应用程序来进行测试。如果您有兴趣提供您的 .NET Framework 1.1 应用程序，请发送邮件至 netfxcmp@microsoft.com。
破坏性更改的定义破坏性更改是那些在 .NET Framework（运行库破坏性更改）或 Visual Studio（design/compile/project 升级）中使某些应用程序或开发方案行为异常的更改。这些更改不一定是那些我们已发现的破坏应用程序的更改；更准确地说，这些更改是在设计检查和测试过程中发现的行为更改，它们有可能影响应用程序。实际上，在我们所有的应用程序兼容性测试中，发现的影响应用程序的更改不到十个。
运行库更改可以分为两类：第一类（也是最少见的）是 API 破坏性更改，包括更改函数签名或删除函数。几乎在所有情况下，这些更改都是出于安全考虑。在整个 .NET Framework 2.0 中，此类更改不到 5 个。
第二类（较常见的破坏性更改类型）是行为破坏性更改，包括更改方法的行为。此类更改的示例包括：更改由于特定错误而引发的异常，以及更改浮点操作的精度。
.NET Framework 2.0 中所有已知的破坏性更改都经过了仔细检查，并且记录在此处以用于 Beta 2。进行破坏性更改的原因有许多，包括符合标准、客户反馈以及正确性问题。我们已经尽量详细地记录这些更改，但我们相信其中的很多更改仍会影响到少量用户。每种类型的运行库更改的示例都遵循以下原则：
•
符合标准：Kyrgyzstan 的 System.Globalization 中的 ISO 标记从 KZ 更新为 KY。
•
符合标准：ASP.NET 中呈现的 HTML 更新为符合标准的 XHTML 1.0 Transitional。
•
客户反馈：更改了 ASP.NET 项目模型以响应客户反馈。
•
正确性：已经在某些情况下增加了浮点精度。这已经作为一种可能性记录在 CLI 规范中。
正如所有的测试版产品一样，我们正在寻求更多的反馈。如果您遇到有关 Beta 2 产品的问题，请通过 MSDNProductFeedbackCenter 向我们报告。有关部署和兼容性的问题，请发送邮件至 netfxcmp@microsoft.com。我们将根据收到的反馈来更新 .NET Framework 2.0 版本的破坏性更改列表。
应用程序加载机制和可能的问题默认情况下，使用 .NET Framework 构建的应用程序将使用构建时所用的 Framework 版本（如果已在计算机上安装该版本）运行。下表指定了目标计算机上不同 .NET Framework 配置下的应用程序的加载行为。
应用程序类型
安装 1.1 的计算机
安装 2.0 的计算机
同时安装 1.1 和 2.0 的计算机
1.1 独立应用程序（Web 或 Microsoft Windows 客户端）
使用 1.1 加载
使用 2.0 加载
使用 1.1 加载
2.0 独立应用程序（Web 或 Microsoft Windows 客户端）
失败
使用 2.0 加载
使用 2.0 加载
本机应用程序的1.1 外接程序（例如 Office 或 Internet Explorer）
使用 1.1 加载
使用 2.0 加载
如果没有将进程配置为在 1.1 中运行，则使用 2.0 加载
本机应用程序的 2.0 外接程序（例如 Office 或 Internet Explorer）
失败
使用 2.0 加载
使用 2.0 加载
在通过 .NET Framework 2.0 加载使用 .NET Framework 1.1 构建的应用程序代码并遇到破坏性更改的情况下，该应用程序可能失败。在上面的表中，粗体单元格表示可能出现这些情况的地方。以下部分提供有关如何在这些情况下减少潜在问题的信息。
在 .NET Framework 2.0 中测试使用 .NET Framework 1.1 开发的应用程序由于应用程序将使用构建时所用的 Framework 版本运行，因此有两种能够使用 .NET Framework 2.0 运行应用程序的方法：
•
在只安装有 .NET Framework 2.0 Beta 2 的计算机上安装和测试。
•
在已安装有 .NET Framework 1.1 的计算机上安装测试版。使用 gotdotnet.com 上概述的步骤强制应用程序使用 .NET Framework 2.0 运行。
减少可能的兼容性问题的策略 通过遵循如下所述的其中一个策略，开发人员可以减少应用程序受 .NET Framework 更改影响的可能性。兼容性测试方案中提供有关测试的更多信息。
在发布 .NET Framework 2.0 的最终版本之前，我们将检查兼容性状态，并考虑在破坏性更改影响应用程序时还原这些更改。在进行兼容性测试时，如果您发现应用程序需要进行一些更改才能在新版本上正确运行，请在 MSDNProductFeedbackCenter 上记录错误。
1.
测试和修复
始终进行；推荐
使用由 .NET Framework 1.1 构建的应用程序的一种可能方法是：使用 .NET Framework 2.0 测试该应用程序，进行一些必要的更改，并确保该应用程序在 Framework 的两个版本上都能运行。
开发和测试含义这将要求小组测试 Framework 的两个版本，从而扩展应用程序的测试矩阵。它可能还要求开发人员对源代码进行一些修改，以确保应用程序在 .NET Framework 1.1 和 .NET Framework 2.0 上都能运行。
市场和运营含义应用程序所有者需要与客户和用户沟通该问题，并为他们提供兼容 Framework 这两个版本的应用程序更新版本。
2.
使用 .NET Framework 1.1 部署
用于独立的托管应用程序
默认情况下，使用 .NET Framework 构建的托管应用程序将使用构建时所用的版本运行。如果已在目标机器上安装了 .NET Framework 1.1，则不需要更改任何应用程序。要启用该方案，应用程序所有者应该继续连同其应用程序一起发布 .NET Framework 1.1，或确保所有目标机器上都安装有 .NET Framework 1.1。
如果 .NET Framework 应用程序寄宿在本地主机中（例如 Microsoft Office 或 Microsoft Internet Explorer），则该应用程序将使用计算机上安装的最新 .NET Framework 版本。这可能意味着，构建在 .NET Framework 1.1 上的应用程序可能被强制使用 .NET Framework 2.0 运行。如果您编写宿主托管代码的本机应用程序（无论是通过直接宿主还是通过 COM Interop），则可以配置本机 exe 并选择构建托管代码时所用的运行库版本；否则，您的组件需要在计算机上安装的最新版本上运行。有关更多详细信息，请参阅以下并行文档。
开发和测试含义从开发和测试的角度来看，这需要确保在所有机器上安装 .NET Framework 1.1。如果是寄宿组件（加载托管组件的应用程序），您可能需要修改该应用程序的配置文件，以确保即使在该计算机上安装了 .NET Framework 2.0，宿主进程也会加载 .NET Framework 1.1。
市场和运营含义从市场和运营的角度来看，这涉及传达让用户安装 .NET Framework 1.1 的需要。如果是本地主机，当用户在其系统上安装 .NET Framework 2.0 时，它可能还需要让客户和用户安装新版本（或更新应用程序配置文件）。
3.
升级到 2.0：
适用于所有应用程序，但需要安装 .NET Framework 2.0
希望利用 .NET Framework 2.0 中新功能的开发人员应该升级应用程序以使其适合 .NET Framework 2.0。这包括重新编译代码、测试应用程序，以及进行一些必要的更改。
在 Beta 2 中，ASP.NET 开发人员需要了解在项目系统和编译模型中所作的更改，这些更改可能会影响其应用程序升级到 2.0 的方式。基于用户反馈，我们已经实现了对 ASP.NET 项目升级系统的补充，这意味着大多数应用程序只需要进行最少的更改。
开发和测试含义这需要更新应用程序以使其适应所有破坏性更改、在 .NET Framework 2.0 中测试应用程序，以及修改应用程序以利用所有 .NET Framework 2.0 功能。开发人员需要更新应用程序安装程序以发布 .NET Framework 2.0。（请注意：在 Beta 2“保持激活”期间，ISV 可能不会重新发布 .NET Framework 2.0。）
市场和运营含义应用程序所有者需要与客户沟通，并且用户需要安装 .NET Framework 2.0 以及更新的应用程序 BITS。
潜在热点有两个广为人知的兼容性方面热点值得一提：
•
序列化：.NET Framework 不同版本之间的任何序列化数据都可能不稳定，因为序列化依赖于对象的内部结构。这可能会影响序列化到文件中的数据，或者通过 .NET Remoting 为通信而序列化的数据。我们目前正在版本容错序列化方面投入精力，预计可以在发布 Visual Studio 2005 和 .NET Framework 2.0 时提供版本容错序列化。
•
检查 .NET Framework 的特定版本：应用程序将在安装时检查 Framework 的特定版本是否已安装到计算机上，或者在运行时检查 Framework 的特定版本是否是版本敏感的 (version-brittle)。这在利用托管代码的安装程序中是很常见的考虑。
提交要测试的应用程序我们一直想要扩展用于测试兼容性的应用程序列表，尤其需要业务线应用程序。如果您提交应用程序，将获得以下服务：
•
我们将在最新的 Whidbey BITS 上测试您的应用程序。根据测试的兼容性需求，各个应用程序的测试程度会有所不同。
•
我们将向您报告通过/失败结果和 Microsoft 发现（在失败情况下）的应用程序问题，以及缓解该问题的建议。
•
我们不承诺确保您的应用程序在最新的 BITS 上正常运行。但是，该成果将帮助我们了解客户可能经历的所有兼容性问题。我们将尽力确保现有的应用程序能够在 .NET Framework 2.0 上正常运行。
•
您负责提供以下内容：应用程序、所有必要的前提（测试数据、其他资源），以及有关如何在全新的计算机上安装和运行该应用程序的安装说明。Microsoft 无法测试需要特定于域的资源或者在其中包含真实客户数据的任何应用程序。
我们希望收集的一些附加信息包括：
公司名称
应用程序名称
应用程序类型（Web 应用程序、桌面应用程序、COM 等）
应用程序开发技术（包括语言）
应用程序功能（包括对业务的重要性）
应用程序大小（LOC、模块）
如果您想要提交应用程序，请发送邮件至 netfxcmp@microsoft.com。
付诸行动•
在 2.0 上测试您的 1.1 应用程序并找出是否存在问题。通过 MSDNProductFeedbackCenter 报告这些问题。
•
通过 netfxcmp@microsoft.com 提供其他问题（包括兼容性和部署问题）的反馈。
•
提交要测试的更多应用程序。
附录和背景NET Framework SDK 文档和文章更详细地描述了并行问题，以及如何配置您的应用程序以便为特定应用程序模型（例如，.EXE 应用程序、Web 应用程序或托管 COM 组件）运行特定版本的 .NET Framework。
MSDN 文档
•
.NET Framework Developer's Guide: Targeting a .NET Framework Version
•
Big Red Switch information on GotDotNet
•
.Config file information
•
Side-by-Side Execution of the .NET Framework
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetdep/html/sidexsidenet.asp
•
ASP.NET application in IIS; see .NET Framework Developer's Guide: Configuring an ASP.NET Application for an ASP.NET Version
•
NET Framework Developer's Guide: Side-by-Side Execution for COM Interop
•
Compatibility Considerations and Version Changes
http://www.gotdotnet.com/team/changeinfo/default.aspx
并行 Framework 和功能的相关背景
存在多个版本的 .NET Framework（v1.0、v1.1、v2.0）。多个 .NET Framework 版本可以“并行”安装在同一台计算机上，同样，用户可以安装诸如 Office 这样的应用程序的多个版本（例如，在同一台计算机上安装 OfficeXP 和 Office2003）。在 Windows XP 和 Windows Server 2003 上，多个 .NET Framework 版本可以在不同的进程中并行运行。换句话说，一个进程可以在 .NET Framework 2.0 上运行应用程序，同时其他进程也可以在 .NET Framework 1.1 上运行应用程序。
.NET Framework 1.0、1.1 和 2.0 上应用程序的并行运行库行为
托管应用程序：在 .NET Framework 1.0、1.1 或 2.0 上启动应用程序时，CLR (mscoree) 会查看该应用程序中记录的 .NET Framework 版本，并尝试在编译该应用程序的 .NET Framework 版本上运行该应用程序。如果尚未在计算机上安装该版本，则 CLR 将尝试在最新的 .NET Framework 和 CLR 上启动该应用程序。例如，如果为 .NET Framework 2.0 编译的应用程序在仅安装有 .NET Framework 1.1 的计算机上运行，那么该应用程序将向前兼容以便在 .NET Framework 1.1 上运行。同样，如果为 .NET Framework 1.1 编译的应用程序在仅安装有 .NET Framework 2.0 的计算机上运行，那么该应用程序将向后兼容以便在 .NET Framework 2.0 上运行。
本机应用程序的托管组件：本机应用程序的托管组件是在本机 exe 启动的进程中，直接通过宿主 API 或 COM interop 加载的托管代码。以这种方式加载托管代码时有两个主要方案：
•
方案 1：托管代码是本机第三方应用程序的外接程序
•
方案 2：托管代码是本机应用程序的一部分
在这些情况下，默认行为是加载安装在该计算机上的最新运行库。
在方案 1 中，您无法了解可能在进程中加载了哪些其他托管组件，因此该托管外接程序无法选择要加载哪个运行库，而是必须加载计算机上最新的运行库。
然而，在方案 2 中，托管代码实际上是应用程序的一部分，因此开发人员非常清楚该托管代码需要哪个运行库。在这些情况下，我们建议由应用程序指定它要加载的运行库。如果该应用程序宿主了运行库，那么它应该通过宿主 API 指定准确的运行库（而不是为空）。如果通过 COM interop 加载托管代码，那么应用程序开发人员应该在本机 exe 上放置一个配置文件，并让该配置文件指定某个支持的运行库。
ASP.NET 应用程序：Web 应用程序彼此不同，因为 .NET Framework 的版本通过配置特定的 IIS 虚拟目录进行选择，目的在于通过 IIS 管理工具来使用特定版本的 ASP.NET ISAPI DLL。ASP.NET ISAPI DLL 可以为 Web 应用程序加载相应的 .NET Framework 版本。
