设计从 Visual Basic 6.0 到 Visual Basic .NET 的应用程序迁移策略
设计从 Visual Basic 6.0 到 Visual Basic .NET 的应用程序迁移策略
8/16/2005
Ivá Sanabria
Alexander Góez
Alvaro Rivera
Carlos Maroto
Hédel
Valverde
Federico Zoufaly
ArtinSoft
摘要：本文介绍从 Visual Basic 6.0 到 Visual Basic .NET
迁移项目的整个过程。它涵盖迁移的所有方面：从业务和技术需求分析，到选择迁移方法（包括经过验证的策略和最佳做法）的原则。您将了解到如何通过经过验证的应用程序策略来最小化迁移需要的时间和精力。
适用于：
MicrosoftVisual Basic 6.0
MicrosoftVisual Basic
.NET
MicrosoftVisual Studio.NET 2003
MicrosoftVisual Studio.NET
2005
Microsoft.NET Framework1.1
Microsoft.NET Framework2.0
本页内容
简介
人们对将 Visual Basic 6.0 应用程序升级到 Visual Basic .NET
的正确方式，以及这样的迁移需要的工作量存在着许多误解。本文档旨在作为准备迁移策略的指南。它描述整个迁移项目的各个不同阶段应该考虑的许多因素，以保证项目成功完成，同时也描述从执行多个迁移项目中获得的最佳做法。
之所以考虑 Visual Basic 应用程序现代化，是因为有一些共同的驱动因素。可以将这些驱动因素考虑为一个范围，从推动
因素（Visual Basic 6.0 应用程序必须作出反应以符合一组新的业务需求），到拉动
因素（业务应该抓住机会来培育/争取新的客户，并增加利用当前应用程序的产品和服务）。这些因素包括提高旧有应用程序的维护成本和管理费用的操作和效率，同时最大化使用
.NET 的利益。
迁移、替换、重写或重用？
一旦组织确定某个应用程序不再满足业务的需要，而又不能置之不理时，就需要对其进行现代化。应该仔细研究对 Visual Basic
应用程序进行现代化的一些可选方案。决定性因素是 (i) 应用程序的代码质量和 (ii) 应用程序的商业价值。在这种情况下，质量
指应用程序在商业和技术条件下的适用性，应该根据以下参数对其进行评定：
| · |
当前影响：即产生的错误、工作环境数目、所需的支持级别等等。 |
| · |
核心业务规则的稳定性和完整性：在可预知的未来，应用程序逻辑是否保持相同？本文的基本假设是当前软件资产非常有价值。如果业务模型发生重大改变，则这个假设就有问题。实际上，代码通常只是业务规则的储备库，这些规则分散在整个代码中。因此，任何“从头开始”的尝试都需要对当前代码中捕获的需求重新构造和记录，并将这些需求作为新需求的准备起点。 |
| · |
生命周期的阶段：在生命周期的早期阶段，虽然平台可能过时，但应用程序可能是根据功能需求进行周密设计的。 |
| · |
开发环境：需要评估成功交付一个现代化项目所需的开发团队和环境功能。这时，开发人员关于应用程序源代码的知识、目标技术以及在代码评估过程中所确定的现代化问题的解析很关键。通常，建议执行此项目的开发人员接受过 |
商业价值是另一个重要的考虑事项，它取决于当前应用程序的独特性。如果应用程序的质量很差，并且在第三方软件包中有类似功能，则就需要替换它。
有四个主要的现代化选项 — 迁移、重用、重写或替换，它们是现代化整个应用程序或部分应用程序的正确选择。图 1
显示决定因素与现代化路径相关联的方式。
图 1. 现代化选项图表
| · |
迁移：如果 Visual Basic |
| · |
重用：这里有两种可能性：一种是应用程序已经以第三方软件包/DBMS 为中心，另一种是业务已经从头开始开发自己的应用程序。如果 Visual |
| · |
重写：这里的关键资产是业务规则和数据结构 — 应用程序是问题所在。需要开发应用程序以及分析代码逻辑和数据结构来为重写提供起点。 |
| · |
替换：查找合适的软件包或外部资源。准备更改业务模型以满足正在开发的软件包的需要。 |
做出正确的决策
在项目开始之前，应该进行可行性分析来提供应用程序的业务和技术质量评估。下面的一系列清单列出了在选择一种可选方案时可能要考虑的一些问题。
选择迁移的清单
| · |
现有应用程序满足当前业务的需要。 |
| · |
现有应用程序中需要适度更改功能。 |
| · |
现有应用程序操作成本高。 |
| · |
由于策略原因需要迁移到 .NET Framework。 |
| · |
未来愿景包括 Web 服务或 Web 访问的使用。 |
| · |
稳定的基本代码和证明它的测试套件。 |
| · |
难以发现资源来在现有平台上维护修改的应用程序。 |
选择重用的清单
| · |
业务规则令人满意。 |
| · |
现有应用程序操作成本低。 |
| · |
需要简单的 Web 访问，允许使用包装解决方案。 |
| · |
需要资源才能继续维护核心 Visual Basic 6.0 应用程序。 |
| · |
现成的软件以已有的软件为中心，依赖于第三方的支持和维护。 |
选择重写的清单
| · |
功能不满足业务需要。 |
| · |
没有现成的解决方案能够非常好地满足需要。 |
| · |
现有平台代码质量低，维护成本高。 |
| · |
能够承受相关的时间、成本和破坏。 |
| · |
由于策略原因需要使用 Microsoft .NET Framework。 |
| · |
未来愿景包括 Web 服务的使用。 |
选择要替换的清单
| · |
应用程序明显不符合业务需要。 |
| · |
愿意对业务模型进行更改以适合现成的解决方案，或者愿意对现成解决方案的可用性进行更改以满足业务需求。 |
| · |
能够承受相关的时间、成本和破坏。 |
以上问题可以应用于完整的应用程序或应用程序的各个独立的部分。通常，一个大型应用程序需要平衡不同的现代化可选方案。当为应用程序的特定部分确定最佳路径时，记住这一点：许多开发人员总是说，如果需要升级，重写应用程序是最佳的解决方案，因为他们经常觉得第二次可以写得更好，因为有后见之明的优势。确实，如果应用程序设计得很差，重写是一个很好的选择，因为它提供一个将它写好的机会。不过，还请研究诸如升级、重写、替换或将应用程序保留在
Visual Basic 6.0 等方面的商业案例，它们都具有一些令人感兴趣的方面。
如果应用程序已经满足业务的需要，则不需要增强功能，而且如果让支持人员接受 Visual Basic 6.0 培训，则将应用程序保留在 Visual
Basic 6.0 中是个很好的选择。尽管如此，您的组织还需要在 Microsoft Product Family Life-Cycle Guidelines
环境下评估这个选择的风险，以及 Visual Basic .NET 和 .NET Framework
能为您的组织提供的机会。
如果因业务需要，必须将应用程序迁移到 Visual Basic .NET，则需要认真考虑一下重写和升级。对于迁移应用程序来说，使用从 Visual
Basic 6.0 到 Visual Basic .NET 的迁移工具来升级应用程序是一种经济有效的方式。将应用程序迁移到 Visual Basic .NET
的常见原因是使应用程序能够支持 Web，或者增强支持 Web 的现有应用程序，使之具有 ASP.NET
功能（例如跟踪、灵活的状态管理、可伸缩的数据访问和改进的性能）。正如前面提到的，重写有时能使应用程序得以改进。不利方面是开发成本会比升级高。根据
Artinsoft 的咨询实践和软件研究院 (http://www.spr.com) 的研究，经验丰富的 Visual Basic 编程人员平均每月编写 500
到 1000 行可部署的 Visual Basic .NET 代码。同样的编程人员在升级应用程序时将处理 3500 至 4000
行代码。升级速度快了三到七倍！造成如此大差别的主要原因是重写包括编写、测试和调试新算法，而升级只需要保证代码像以前那样运行就可以了。
重写能带来一些好处。重写能让您修正以前的不良设计，而且 COM 对象可以替换为更具可伸缩性的 .NET
对象，同时在部署时不需要注册。而另一方面，升级速度更快，而且可以在升级后将 COM 对象替换为 .NET 对象。
简而言之，必须确定如何开展现代化项目。如果决定最佳解决方案是将应用程序保留在 Visual Basic 6.0
中，那么就大功告成了！另一方面，如果经评估后得出最佳解决方案是重写应用程序，则给您的最好建议是确保遵循一个可接受的开发方法，并且真正分析当前应用程序存在的问题以确保在开展时能利用这些已知情况。如果您认为当前的应用程序及其源代码有价值，将它迁移到
.NET 能够延长其生命周期，则可以确定自动协助迁移是迁移代码的最佳解决方案。最后，可以决定结合使用以上几种解决方案，大多数现代化项目都是这样实现的。
实现自动协助迁移项目
在本文后面的内容中，我们是在您已决定使用 Microsoft Visual Basic Upgrade Wizard
和推荐的方法来升级应用程序这样的环境下描述迁移项目的实现。与传统开发项目一样，软件迁移项目需要最初的规划和设计阶段。在本节中，我们描述一种能够分析、准备和迁移
Visual Basic 6.0 应用程序的方式，并尝试性地提出一些步骤来帮助您规划迁移项目，包括对迁移项目进行范围确定、成本分析和执行等方面。
功能等价
在自动协助迁移项目中使用的一个重要原则就是功能等价，在进行此类项目时极力建议这样做。在 Visual Basic
迁移环境中，这意味着在添加新功能之前，将 Visual Basic 6.0 应用程序迁移到具有相同功能的 Visual Basic .NET
应用程序中。这确保您的应用程序逻辑不会改变，而业务规则在新的应用程序中可用。
功能等价通常被认为是整个迁移项目的一个中间步骤。通常，实现功能等价几乎没有什么商业价值，因此任何迁移计划都需要包括在完成这个中间步骤后打算利用的操作和功能。创建一个功能与原始系统
100% 相同的系统有时被认为是一种不可思议的事情。这种受控方法提供了一些好处，组织很少能意识到这些好处，除非他们真正开始进行重写应用程序的项目。
| · |
它包含系统的完整规范。行为或输出中的差异很容易演示，并且为组织提供一种清晰的方式来衡量迁移项目是否成功。 |
| · |
它是避免为现有应用程序功能制定规范的困难、昂贵且耗时的过程的唯一方式。它防止扩大范围的危险，并且为项目的测试阶段提供方便。不过，在开始之前，仍然需要为新功能制定规范。 |
| · |
它为组织提供一个清晰、简单易懂的方法来跟踪项目进程。 |
| · |
它减轻用户适应新系统的压力，并将整个更改管理过程限制为只由 IT 部门完成。 |
| · |
它是组织从旧技术过渡到新技术的最快捷方式，也是组织重新获得对系统的自主控制权并继续进行正常维护活动的最快捷方式。 |
理解 Visual Basic 迁移过程
在首次迁移项目之前，熟悉迁移过程的细节是很重要的，这样才能确定其范围。要实现这一点，可以选择首先迁移简单的应用程序，直至您和您的团队感觉分析和解决所迁移代码中的一般问题得心应手为止。对于新手而言，最好的做法是避免迁移那些不自动支持升级路径的项目（参见“应用程序分析”一节），或者与其他技术紧密集成的项目。一旦积累些经验，您就能够确定会影响项目执行的问题。
在迁移时，请检查升级工具生成的 Upgrade
Report。升级报告包含有关升级过程的信息和在升级过程中发现的、在项目可以运行之前需要解决的问题列表。理解不同的问题类别和建议的解决方案。
在事先准备 Visual Basic 6.0 代码时，可以减少问题的数量。Preparing Your Code for Migration
一节详细介绍了这一主题。
学习升级与学习其他东西一样；从简单入手意味着以可管理的方式学习。另外，选择简单的项目意味着上手容易并运行得更快，从而确保对进度的把握。
当准备升级一个大型实际应用程序时，选择能受益于 .NET
新功能的项目，这样可以检查过程达到功能等价，然后实现应用程序改进。理解体系结构的修改方式。对于大型应用程序，应用各个击破的原理。推荐的方法是对其进行逐模块升级。例如，可以首先升级客户端模块，接着升级依赖层次结构，然后升级业务逻辑和数据层模块。我们稍后详细描述可能的迁移策略。确保在进行过程中随时测试是非常重要的；在升级应用程序的每个模块时对它进行测试，这样才能知道您是在做好一步之后才进行下一步的。
一旦以上步骤都完成，您就可以确定迁移项目的范围了。
应用程序分析
分析应用程序的目的是为了生成用于估计迁移项目效果的信息，以及创建应用程序的技术配置文件。应用程序分析的输出应该包括以下几项：
| · |
当前和目标体系结构 |
| · |
迁移清单 |
| · |
源代码规格 |
| · |
处理不支持的功能 |
| · |
评估升级报告信息 |
当前和目标体系结构
理解应用程序的当前体系结构和在目标体系结构中其组件的替换方式。例如，可以考虑将 ADO 替换成 ADO.NET，将 ActiveX 组件替换成本地
.NET 组件。最后得到的目标体系结构也应该包含这些新块，它们支持新的应用程序需求。这些新块是作为新需求分析和设计的一部分产生的。
有可能您迁移的应用程序与其他现有的 Visual Basic
应用程序、模块或组件相交互，所以您可以决定重用这些应用程序部分，而不是迁移它们。确定应用程序体系结构中的这些交互并确保清楚理解哪些组件需要交互以及在哪交互。还要确定一些组件，这些组件在
.NET 中有可用的等价组件，可以使用这些组件来替代。
迁移清单
确定要升级的相关源代码。这应该包括库、资源和组件。以应用程序调用关系图的树状视图形式存在的依赖关系图可以帮助您认识所有需要的 Visual Basic
6.0
项目和文件。在决定关于废弃代码的处理方式时，可能将它作为清单的一部分，也可能将它部分排除或完全排除。如以下几节提到的工具可以帮助您从源代码和通过确定废弃代码取得依赖关系。
另外，确定那些要迁移的应用程序部分和只是重用的应用程序部分（如果有），包括应用程序当前使用的所有组件。对于第三方组件，确定本地 .NET
等价组件的可用性。
源代码规格
从应用程序源代码获取规格信息。此信息应该包括大小规格，如代码行、项目、窗体、设计器、模块、类、组件、用户控件和数据源的数目；以及使用规格，如使用的函数、类型、组件和变量，包括在哪使用。
获取应用程序中每个组件的使用频率。此信息连同组件的使用方式有助于确定在迁移应用程序之后以等价的本地 .NET 组件来替代它有多大难度。
下面的屏幕快照显示 VCR
源代码的示例规格。它给出数据类型和控件出现频率的部分信息、源代码清单（以树状形式给出）和数据类型的具体使用位置，在本例中为整型和字符串类型。
图 2. VCR 示例的部分源代码规格的示例屏幕快照
有工具可以分析 Visual Basic 6.0 代码并生成带有上述信息的报告。这些工具示例是 Aivosto 的 Project
Analyzer 和 WhippleWare 的 VB Compress Pro。
处理不支持的功能
确定所有在 .NET 中不受支持的 Visual Basic 6.0 功能以及它们在应用程序中的使用频率。研究及原型分析在 .NET
中可能满足需求的实现可选方案，并确定所有其他支持功能。
下面是在 .NET 中不受支持的功能的非完全列表，并在可用时给出试验性解决方案。
| · |
动态数据交换 (DDE)：DDE 方法不再受支持。依赖 DDE |
| · |
DAO 或 RDO 数据绑定：Visual Basic .NET 中不支持数据绑定到 DAO 或 |
| · |
Visual Basic 5 控件：Visual Basic 6.0 包含 Visual Basic 5.0 版的 |
| · |
DHTML 应用程序：在 Visual Basic .NET 中没有等价控件。然而，DHTML 应用程序可以和 Visual |
| · |
ActiveX 文档：在 Visual Basic .NET 中没有等价控件。然而，ActiveX 应用程序可以和 |
| · |
属性页：在 VisualBasic .NET 中没有等价控件。如果您的应用程序很大程度依赖于属性页，则应该保留在 Visual Basic |
| · |
Web Class：它们在 .NET 中部分受支持。另外，Web Class 可以和 Visual Basic .NET |
| · |
OLE 容器控件：在 Visual Basic .NET 中没有等价控件。在使用这个功能的应用程序中，可以使用 |
| · |
单层数据库应用程序：因为不支持数据绑定到 DAO，所以使用控件直接绑定到本地数据库（例如采用 Microsoft Access |
| · |
Visual Basic 外接程序：因为 Visual Basic .NET 使用 Visual Studio |
| · |
游戏：依赖 Visual Basic 6.0 的特定性能特征（例如拱廊游戏）的应用程序需要重做，因为 Visual Basic.NET |
| · |
图形：窗体或形状和线段控件的图形方法不支持自动升级。大量使用这些功能来绘制窗体的应用程序需要重做不少工作。 |
| · |
拖放功能：拖放功能的模型有很大不同。任何执行拖放操作的代码都需要重写。 |
| · |
Windows API：Windows API 可以迁移。然而，由于语言更改，可能要将许多对 Windows API |
| · |
Printer：不支持此对象。在代码中大量使用这些功能来打印的应用程序需要重做不少工作。类似的功能可以在 |
| · |
Printers 集合：Visual Studio .NET 中不再支持此集合。在 Visual Basic 6.0 中，使用 |
| · |
Forms 集合：此集合在 Visual Studio .NET 2005 中部分受支持。使用该集合的应用程序需要部分重写。 |
| · |
ClipBoard 对象：此对象在 Visual Studio .NET |
| · |
函数：有些函数，如 |
| · |
GoSub：在 Visual Basic .NET 中，不再支持 Gosub…Return 和 |
| · |
无法解析晚期绑定默认属性引用：在 Visual Basic 6.0 |
| · |
TypeOf：在 Visual Basic 6.0 中，在 If…Then…Else 语句中使用 |
| · |
事件参数没有升级：Visual Basic 6.0 中支持的一些事件参数在 Visual Basic .NET 中不再受支持。 |
| · |
PopupMenu：此函数在 Visual Studio .NET 中不再受支持。新的 Visual Studio .NET |
| · |
ClipControls：这些控件不再受支持，像 Line 和 Circle 之类的函数在 Visual |
| · |
License 集合：LicenseInfo 对象的一个集合，它包含在向 Controls |
| · |
Enum 中的常量：Visual Basic 6.0 枚举成员通常被升级为整型值。在 .NET 中，这些枚举成员不一定对应 |
| · |
鼠标指针：像在 Visual Basic 6.0 中那样在 Windows 窗体中将 MousePointer 设置为 |
升级报告信息评估
升级报告提供应用程序中遇到的所有升级问题以及它们的出现次数。每个问题类型是由一个问题号、一个描述和一个指向相关文档（包括可能的后续步骤）的链接确定的。例如，问题号
1037 对应于“晚期绑定默认属性引用无法解析”这一问题。出现问题的主要原因如下：
|
1. |
不支持的功能（请参考处理不支持的功能 一节）。 |
|
2. |
一小部分 Visual Basic 6.0 核心功能在 .NET 中没有等价功能或显示新行为的核心功能。 |
|
3. |
ActiveX 控件迁移到 .NET 控件，但这些 ActiveX 控件的一些成员不受 .NET 控件所支持。例如，当升级到 .NET |
|
4. |
对于语言更改，Visual Basic Upgrade Wizard 会主动警告您并请求您手动检查，就像在 Visual Basic 6.0 |
以下来自 ArtinSoft 咨询实践的数字表明，经常发生的前十个问题占全部升级问题的 94.5%。这个数字是从迁移 Visual Basic 6.0
项目获得的，它对应 1,470,000 行代码，而 Visual Basic Upgrade Wizard 报告的问题总共有 16,507 个。也就是说，每
90 行源代码就有一个问题。当对源代码做些迁移准备时，这个数字可以提高到每 120 行代码一个问题。
| 问题 | 描述 | 出现频率 (%) |
|
1037 |
52.3 |
|
|
2064 |
12.6 |
|
|
2065 |
11.6 |
|
|
1060 |
6.6 |
|
|
1049 |
4.4 |
|
|
2072 |
2.9 |
|
|
1041 |
1.7 |
|
|
2069 |
0.9 |
|
|
1039 |
0.8 |
|
|
2075 |
0.7 |
很明显，应用程序中前十个问题所占比例会因其体系结构而改变。
要分析应用程序中的升级问题，有一个基本的要求，那就是要理解它们可以分成两大组：
| · |
不能升级或不支持的问题：这些问题表示存在不支持的功能（请参考处理不支持的功能 Artinsoft 的咨询实践经验表明，一旦不支持的功能得以解决，本组中其余问题中的 95% 都能通过在 .NET |
行为不同的问题：这些问题表示迁移的代码存在与原始代码不同的新行为，应该在代码上下文中手动检查可能的后果，以防可能需要修改。本组中的问题不会阻碍迁移应用程序成功编译，但可能产生运行时错误，使得迁移的应用程序失败。Artinsoft
关于本组中的问题的咨询实践经验为：
| · |
它们中只有一小部分需要手动干预。 |
| · |
在对迁移的应用程序进行单元测试时，它们能够提供指导。由于这个原因，建议您在静态检查代码时不要删除它们，但在成功完成单元测试后要删除。 |
对于其中每组问题，确定不同的问题编号及其发现频率，如上表所示。首先分析最常发生问题的可选解决方案和实现效果。其次，分析所有无法升级或不支持的问题，因为它们是任何迁移中工作量的重要来源，然后是行为不同的问题。获取有用效果信息的实际方法是运行试验性迁移练习，从中解决大部分问题（如果不是全部）。在试验中也可以评估新的需求。
范围定义
根据从需求分析和设计阶段获取的业务和技术需求，范围定义的输出应该是迁移范围的定义。在确定迁移项目的范围时，对所预见的主要迁移问题的解决是否需要（概念证明意义上的）原型分析进行评估，例如处理不支持的功能或重新架构。这有助于避免在迁移应用程序时将时间浪费在糟糕的代码设计上，这允许您事先在独立的条件下检验任何解决方案，并为您提供有价值的数据来估计迁移成本。
您的基础结构为更改做好准备了吗？迁移的应用程序及其组件能够在现有的平台上运行吗？确定要衡量的功能等价的实现方式。要衡量功能等价，要先确定现有测试套件和/或创建一套新的测试用例，也称为等价准则，并准备好测试机制以在迁移的应用程序中加以检验。通过这种方式，等价准则将成为一个很有用的机制，用它衡量迁移过程可以确定什么时候达到功能等价，并避免转移目标。
为代码做好迁移准备
如果在迁移前在 Visual Basic 6.0 中采取步骤来为应用程序做些准备，则升级将会更快，这一点几乎无例外。以下是在代码准备阶段的建议步骤：
|
1. |
确定要升级的整个源代码清单。 |
|
2. |
确定在此源代码中 Visual Basic 6.0 项目之间的依赖关系。对于 Visual Studio 的 Project References 和 |
|
3. |
确保这些项目需要的所有 dll 都恰当地安装在将做升级之用的机器上。以下步骤的成功执行表明所有 dll 都已安装。 |
|
4. |
确保编译所有 Visual Basic 项目。使用 Make exe/dll 命令来实现此目的。 |
|
5. |
使用 Visual Basic 6.0 Code Advisor 来检查和调整源代码。Visual Basic |
|
6. |
Code Advisor Report 为您提供以下问题的详细信息：结构问题，如在 Visual Basic 6.0 项目中存在的控件在 .NET |
|
7. |
使用 Visual Basic Upgrade Wizard 来运行每个 Visual Basic 项目的原始迁移并检查产生的 Upgrade Reports。查找升级警告 1037 |
|
8. |
检查可能适用于源代码的准备建议。 |
您可能需要反复进行这些步骤才能确定您的代码是否为迁移做好充分的准备。
迁移速度将取决于源代码的特征：例如，定义为变量的单变量在以后每次引用该变量时都会产生一个升级问题。这样会产生大量问题。Artinsoft
的咨询实践显示，在 Visual Basic 6.0 中，在准备阶段每解决一个升级问题，都将使 Visual Basic Upgrade Wizard 少出现
5-8 个问题。以下表格对应于该实践的一个示例。
| 描述 | 数量 |
|
LOC 中的 Visual Basic 6.0 项目示例 |
50117 |
|
最初的问题数目 |
1301 |
|
Visual Basic 6.0 代码准备更改 |
58 |
|
准备后产生的问题数目 |
982 |
|
因准备而避免的问题数目 |
319 |
|
因准备更改而避免的问题数目 |
5.5 |
升级用 Visual Basic 早期版本编写的应用程序
Visual Basic Upgrade Wizard 是为升级 Visual Basic 6.0 应用程序而设计的。对于用 Visual Basic 第
1 版到第 5 版编写的项目，需要先将它们升级到 Visual Basic 6.0，然后才能升级到 Visual Basic .NET。要将项目升级到
Visual Basic 6.0，只需要在 Visual Basic 6.0 中打开该项目，并保存即可。如果 Visual Basic 6.0 提示将控件升级到
Visual Basic 6.0 版本，则选择 Yes。如果项目包含 Visual Basic 5 ActiveX
控件，通常最好的做法是将它们替换成 Visual Basic 6.0 版本。这是因为这些控件使用与 Visual Basic 6.0 控件不同的线程模型，这在
Windows 窗体中不受支持。
对于以 16 位的 Visual Basic 版本（1、2、3 和 4）编写的项目，可能需要对迁移的项目进行额外修改才能使它在 Visual Basic
6.0 中工作，因为有些 VBX 控件不会自动升级。还得将 Win16 Windows API 替换成它们相应的 Win32 API。
Visual Basic 第 2 版和第 3 版通常需要一个额外的步骤。Visual Basic 6.0 只能以 Text 格式打开文件，而
Visual Basic 第 2 版和第 3 版支持两种文件格式：Binary 和
Text。在升级这些项目之前，要确保整个应用程序保存为 Text 格式。要做到这一点，选择项目中的每个文件并选择
File|Save As 菜单项。在弹出的 Save 对话框中，选中 Save As Text 复选框。由于
Visual Basic 1 只能保存为“Binary”格式，所以这些项目需要在 Visual Basic 2 或 3 中打开并保存为文本格式，才能升级到
Visual Basic 6。在完成这些步骤之后，就可以将新创建的 Visual Basic 6.0 项目升级成 Visual Basic .NET。
迁移策略定义
一旦决定迁移现有应用程序的部分或全部，就需要确定如何最佳地迁移到
.NET。一般条件下推荐使用传统的逐模块策略，并非所有情况都适用，这主要取决于应用程序体系结构或大小。在这种情况下，您就需要按照以下方式之一进行迁移：
| · |
纵向迁移，指隔离和替换所有 n 层应用程序的一块。 |
| · |
横向迁移，指替换一整层应用程序。 |
要确保功能等价与选择的策略无关，就需要为整个系统以及各个迁移模块、层或块集合全部单元和系统测试套件。
接下来我们将更加详细地介绍横向和纵向应用程序迁移策略，以帮助您根据应用程序体系结构来确定合适的解决方案。策略的选择应该与应用程序体系结构紧密相联。
纵向迁移
在纵向迁移策略中，迁移确定和选择的应用程序部分跨越应用程序的几个层（如果不是全部）。从根本上讲，它包括划出一个与其他应用程序块的交互最少的应用程序块，并迁移它。
如果应用程序各个部分相互间的独立性很好，则纵向迁移就是一个好的选择。这种独立部分通常与应用程序的其余部分共享非常少的状态信息，迁移方便，而且对系统的其余部分影响很少。如果迁移时需要向其中任何部分添加新的功能，则极力建议使用
.NET Framework 来开发这样的新功能。
以下方案代表两种情况，它们的最佳选择是纵向迁移策略。
各层之间大量使用ADO记录集
许多应用程序将断开的 ADO 记录集从数据和业务层传递到表示层。然后表示层循环访问该记录集并生成 HTML
表格。这类应用程序很适合纵向迁移。例如，在这种情况下，将 ADO 集中迁移到 ADO.NET 将使与 ADO 实现互操作性所需要的工作量降到最少。
计划重新设计
使用纵向迁移策略将部分应用程序迁移到新的体系结构可以为新的设计提供一个良好的测试基础。.NET Framework
已准备好提供新的体系结构支持，以使得在新的体系结构上构建迁移变得更加容易。例如，可以在 .NET 中使用 HttpHandlers 来执行许多以前使用
ISAPI 扩展执行的任务，同时还提供一个更加简单的编程模型。
当采用纵向策略时，一旦迁移了选择的应用程序部分，新的托管代码和现有非托管代码之间的任何集成都通过互操作性完成。您需要进行一些开发和测试工作，以确保站点新旧两块协同工作和共享数据，并为最终用户或客户端开发人员提供无缝体验。在这之后，您就有了基本的基础结构，这样就可以使用相同的纵向方法迁移系统中的其他应用程序，或者扩展系统的已迁移部分。
横向迁移
在横向迁移策略中，向 .NET 迁移的是应用程序的整个层，而没有立即迁移其他层。通过一次迁移一层，可以使用 .NET Framework
为该特定层提供的特定功能，在许多情况下不用修改应用程序代码或影响其他应用程序层的操作。
横向迁移策略的第一步是确定先迁移哪个层。
中间层 COM 组件迁移到 .NET 可以很少或不用更改表示层。在确定横向迁移策略是否合适，并且如果合适，最适合迁移哪个层时，应该考虑以下几点。
| · |
大量 Web 服务器：部署 Visual Basic .NET 应用程序的一个先决条件是必须在每台 Web |
| · |
共享代码迁移：如果中间层中出现大量共享代码、常量或自定义库（Visual Basic |
| · |
复合中间层：中间层中的复合对象层次结构应该保留为一个单元。对于带有复合中间层对象层次结构的应用程序，确定从哪分隔是很困难的，而且只迁移复合中间层的一些部分通常需要在不同环境之间进行无数互操作性调用，导致性能降低。 |
在替换中间层时还应该考虑以下问题：
| · |
要将中间层组件透明地替换成 .NET 组件而不影响客户端代码，您需要维护 COM 组件的原始 GUIDS 和/或 ProgId。 |
| · |
在尝试透明替换 COM 组件时，要适当地处理 Visual Basic 组件生成的类接口的替换。 |
| · |
将迁移的中间层组件返回的 ADO.NET 数据集转换成在原始 Visual Basic 代码中使用的 ADO 记录集。 |
| · |
为中间层组件部署互操作性程序集。 |
成本估计
估计软件开发项目中的成本和时间通常是项很复杂的任务，因为软件实现的质量和软件团队的编程能力参差不齐。代码迁移也不例外。升级应用程序需要进行多少工作受许多因素影响。这些因素会导致不同应用程序之间和不同组织之间的成本相差一个数量级。基于此原因，我们介绍了成本驱动力，需要在应用程序和基础结构环境下对它进行评估以估计迁移成本。
以下是估计应用程序最终迁移成本时建议要考虑的成本驱动力：
| · |
未处理功能的解决：对于其中每种功能，要估计可选解决方案的研究成本、选择的解决方案可能需要的任何支持功能的开发和测试成本，以及在迁移的应用程序中以出现频率为倍数的未处理功能的替换成本。 |
| · |
报告问题的解决：对于升级报告中的所有问题，估计解决成本。对此，建议对应用程序有代表性的部分进行一个试验性的迁移练习，以获取问题解决成本的准确信息。这也能对团队交付所迁移应用程序的能力进行一个有价值的了解。 |
| · |
测试：针对应用程序中的每个 Visual Basic 另外，除了在 Visual Basic 6.0 版本上执行普通测试（通常是局部测试）外，还要理解迁移的 .NET |
| · |
将 Visual Basic 6.0 组件替换成 .NET 等价组件：对于计划替换成 |
| · |
第三方 .NET 组件：从相应的提供商获取计划在迁移的应用程序中使用的所有 .NET 组件的许可成本。 |
| · |
新需求：通过在软件开发项目中的组织经验来估计所迁移应用程序中的新需求的设计、开发和测试成本。 |
| · |
部署：估计迁移的应用程序的部署成本。.NET 一般会提出比旧的基于 COM 的应用程序更加简单的部署机制。 |
另外，组织中还可能存在其他成本驱动力，需要作为成本估计的一部分。寻找这些其他成本驱动力的明智做法是利用您为其他软件开发项目估计成本的组织经验。组织中典型的成本驱动力有以下几个例子：可用的技术资源、开发和测试团队的准备情况和可用于采用新技术的基础结构。
使用所有这些信息，就可以估计迁移项目所需要的成本（人时）。Artinsoft
的咨询实践所得到的经验表明，传统项目和迁移项目结构之间最显著的区别在于：传统项目的测试占总成本的 20% 至 30%，而迁移项目的测试很容易就占到 60% 至
70%，其中迁移项目的绝对小时数小许多。
迁移计划
在为 Visual Basic 迁移做计划时，我们建议您的项目计划除了为组织在执行软件开发项目时通常要包括的那些任务分配时间外，还应该为以下活动分配时间：
| · |
范围定义和修正 |
| · |
当前和目标体系结构 |
| · |
分析和设计新需求 |
| · |
选择迁移策略 |
| · |
迁移清单 |
| · |
源代码准备 |
| · |
源代码规格 |
| · |
处理不支持的功能 |
| · |
升级报告信息评估 |
准备每个项目
| · |
使用 Visual Basic Upgrade Wizard 迁移项目 |
| · |
稳定性（无法升级/不支持问题的解决）和（不同行为问题的解决） |
| · |
单元测试 |
| · |
清理和释放 |
| · |
功能等价验证 |
| · |
实现新需求 |
| · |
接受测试 |
| · |
部署 |
所有这些任务本文前面都已讨论。
执行迁移
根据 Artinsoft
的咨询实践，迁移应该采用哪种方式执行是由几方面信息共同确定的：迁移策略的选择、所选应用程序项目的迁移顺序、升级报告信息以及应用程序的依赖关系图。极力建议从具有最少依赖项并且只有少量无法升级或不支持问题的项目开始迁移（请参考评估升级报告信息
一节）。
对于每个 Visual Basic 6.0 项目，一般迁移过程由以下任务组成：
|
1. |
使用 Visual Basic Upgrade Wizard 升级项目。 |
2.
通过以下方式使迁移项目保持稳定：
| · |
使其成功编译。这意味着解决了所有无法升级/不支持的问题。 |
| · |
检查不同行为问题的报告情况。 |
|
3. |
对迁移的项目进行单元测试。 |
|
4. |
将源代码从升级记录和问题注释中清理掉，并使用相同的迁移过程来为要实现的新需求和其他与之有关的要迁移的项目发布迁移项目。 |
图 3. 应用程序中每个项目的迁移过程
如果在迁移前为代码做些准备工作，则此过程会更快（请参考 Preparing Your Ccode for Migration）。
请注意，Visual Basic Upgrade Wizard 未知的第三方 ActiveX 和 COM 组件不会自动替换成 .NET
等价组件，而是通过互操作性来使用。这里通常不会产生什么问题，但如果计划将它们替换成某个等价的 .NET 组件，则需要手动替换它们。
小结
尽管有挑战，但对于那些花费太多时间和金钱来维护过时信息系统的商业价值的组织而言，对应用程序进行现代化是至关重要的。另外，行业向基于 Internet
的新平台（包括 .NET）转移也促使他们需要更改。这个新的计算范例使用 Web
服务，在内部或与合作伙伴一起利用可自动操作业务过程的基于组件的分布式计算模型。采用更新的计算系统可以缩小操作成本，并使采用 IS
来应对市场变化或竞争压力变得更加容易。
有多种不同的选择，包括以打包的应用程序或非插入措施（如屏幕抓取和代码包装）来替换系统。每种方法都只能在特定环境下使用。采用后一种方法可以快速而低成本地访问旧有功能，而前一种方法可以消除因代码质量太差而无法迁移的过时应用程序。但对于那些想将
Visual Basic 6.0 系统的功能保存并扩展到 .NET 的公司来说，使用今天的自动化工具来迁移可能是最经济的方法了。
本文，我们详细描述了如何处理 Visual Basic 6.0 项目到 Visual Basic .NET
的迁移。我们提供一个清单来帮助您决定如何处理应用程序的现代化，并提供大量关于如何降低迁移项目对 IT 计划造成的影响的最佳做法。
每个 Visual Basic 6.0
系统都需要通过本文提供的透镜来观察。最终目标是尽可能多地恢复当前应用程序的有用逻辑，同时又为现代体系结构的部署做好准备。这些目标并不矛盾，它们可以同时达到，从而最小化迁移成本和风险，并确保在未来几年内向
.NET 应用程序演变。
