小村软件有限公司
联系我们
菜单

VB6 应用能用到什么时候 ── 运行时支持现状与务实的 .NET 迁移做法

· · VB6, .NET, C#, 遗留技术, 存量资产利用, 迁移, 现代化改造, 32bit, Windows 开发, 判断表, 技术咨询

“这套 VB6 系统，能用到什么时候？”──在既有系统的咨询中，这是最常出现的问题之一。

答案其实出乎意料地明确：Microsoft 已经正式发布了支持政策。只不过内容是“运行时暂时还能用，但开发上的后盾已经没有了”这种不对称的状态。如果不能正确理解这种不对称性，就容易陷入“还能用就没问题”与“现在必须全部重做”这两种极端结论之间。

本博客在《VB6 / Access 业务应用的延续与迁移 ── 保留・封装・替换判断表》中，整理了该如何处理VB6 资产的判断方式。本文作为后续，将深入探讨在决定“替换(迁移)”之后，或者为了做出这个决定，实际上该如何推进 VB6 到 .NET 的迁移。

1. 先说结论

  • VB6 的 IDE(开发环境)已于 2008 年 4 月 8 日终止支持。已经没有受支持的方式可以创建或维护 VB6 应用，Microsoft 强烈建议改用现代技术。1
  • 另一方面，VB6 运行时在“搭载的 Windows 支持期间内”属于支持对象。支持对象操作系统列表中包含 Windows 11、Windows 10、Windows Server 2025 等，目标是让现有应用“原封不动地运行(It Just Works)”。2 也就是说，“能用到什么时候”的答案是：仅就运行而言，只要 Windows 的支持持续，就能继续运行。
  • 不过支持范围仅限于处理现有应用的严重回归问题与重大安全问题。此外运行时仅支持 32bit，在 64bit Windows 上只在 WOW64 环境中受到支持。2
  • 真正的风险不是“无法运行”，而是无法修复。IDE 的获取与维护一年比一年困难，所依赖的 OCX 厂商支持中断，会写代码的人也在陆续离职。这三件事都与 Windows 的支持期限无关，会持续发生。
  • 迁移的推进方式有全面重写、自动转换、分阶段迁移三大类。最先要确定的不是方式，而是资产盘点，先摸清界面数量、外部集成、OCX、API 声明的规模，再选择方式。
  • 迁移目标语言方面，新编写的部分建议采用 C#。VB.NET(Visual Basic)已被官方明确定位为稳定路线，不会新增语法，也不会扩展到新的工作负载。3

2. “能用到什么时候”的准确答案 ── 如何解读支持政策

Microsoft 的 VB6 支持政策，将 VB6 分成三个构成要素来说明。2

构成要素 内容 支持状况
VB6 IDE 开发环境(Visual Studio 6.0) 已于 2008 年 4 月 8 日终止
VB6 运行时 msvbvm60.dll 等搭载于操作系统中的运行基础 搭载的 Windows 支持期间内予以支持
运行时扩展文件 主要的 OCX 控件类(随应用程序一并再分发) 同上(需由应用程序方负责分发)

支持对象操作系统列表中，Windows 11、Windows 10、Windows Server 2012～2025 均明确标注为“运行时：支持”“IDE：不支持”。2

解读时有三个要点。

第一，运行时的支持完全从属于 Windows 的生命周期。并不存在“VB6 运行时支持截止日期”这种独立日期，所使用 Windows 的支持结束日就是期限本身。

第二，支持的实质内容更接近于“维持运行”的保证。受理的仅限于严重回归(因操作系统更新导致现有应用损坏)与重大安全问题，不包括个别调查或功能改进。2

第三，VB6 应用今后也只能以 32bit 进程的形式存续。运行时仅支持 32bit，在 64bit 操作系统上只在 WOW64 模拟环境中受到支持。2 一旦出现需要与 64bit 专用 DLL 或 SDK 集成的需求，单一进程就无法独自完成任务。跨越这道墙的方法，我们在《从 32bit 应用调用 64bit DLL 的 COM 桥接实例》中有详细说明。

3. “能运行”与“能维护”是两回事

只看支持政策，可能会觉得“不需要着急”。但在实务中，开发与维护环境往往比运行环境更早崩溃。

  • 无法准备好 IDE。VB6 IDE 在现行操作系统上不属于支持对象，正式的获取方式与安装方式一年比一年难以维持。“公司里只剩一台能修改的机器”这种状态并不罕见。
  • 第三方 OCX 的厂商支持已经中断。支持政策本身也明确指出，第三方制作的控件属于厂商的责任范围。2 表格或报表用的 OCX 已经无法获取的情况相当多，这项判断可以直接套用《ActiveX / OCX 现在该如何处理》中整理的内容。
  • 会写代码的人不再有了。这不是语言规格的问题，而是人的问题。几乎没有新的技术人员在学习 VB6，因此能维护的人数只会持续减少。
  • 周边需求撞上 32bit 的墙。新的设备 SDK、认证库、云集成等，逐渐以 64bit 与 .NET 为前提，无法纳入 VB6 进程的需求越来越多。

也就是说，“能用到什么时候”只是问题的一半。另一半是“下次需要修复时，是否还留有能够修复的团队与环境”。迁移计划不应等到出现故障之后才制定，而应该趁还有能修复的人和环境时就先规划。

4. 迁移方式的判断表

即使决定“替换”，实际做法也有多种。以下整理主要的几种方式。

方式 概要 适合的情况 主要风险
全面重写 重新梳理规格，用 .NET 全新构建 界面数量少 / 想重新审视业务流程本身 / 规格能够说清楚 隐藏业务规则遗漏、并行开发周期拉长
自动转换工具 用转换工具将 VB6 代码机械式转换为 .NET 代码，再由人工完成收尾 代码量大，想保留原有逻辑 / 不改变界面布局 转换后代码的质量与可读性、最终仍会残留的人工工作、工具费用
分阶段迁移(绞杀者模式) 以功能为单位切出，让新旧并存并依次替换 业务无法中断 / 界面与功能众多 / 想分散风险 新旧并存期间的复杂度、边界(集成部分)的设计能力要求高
维持现状＋文档化 不迁移，通过固定环境、备份、文档化延长使用寿命 几乎没有变更需求 / 可以固定设备与操作系统 上一章的风险并未消除(只是往后推迟)

该选择哪一种，并非仅凭代码行数就能决定。Microsoft 官方在迁移时也会连同正式指南一起引导用户借助升级与迁移合作伙伴(包括迁移工具厂商)的力量1，机械式转换这个选项确实真实存在。不过无论选择哪种方式，下一章的资产盘点都是共同的必要前提。

另外，选择“维持现状＋文档化”时的实务做法(固定运行环境、备份、如何承担风险)，我们在上一篇 VB6 / Access 文章中已有说明。

5. 迁移前的资产盘点 ── 动手写代码之前该调查的事

估算与方式选定的准确度，取决于资产盘点的准确度。至少应将以下内容列成清单。

  1. 界面与报表清单 ── 窗体数量、实际被使用的界面(迁移未使用的界面只是浪费)、报表的种类与输出目标(直接打印机打印，还是经由 Excel)
  2. 外部集成清单 ── 数据库(是 ADO/DAO/RDO 中的哪一种，连接目标是什么)、文件输入输出、串口・套接字通信、对其他系统的调用
  3. OCX / ActiveX / COM 引用清单 ── 可以从项目文件(.vbp)的引用中机械式提取。各组件是否还能获取、有无替代方案，直接关系到方式的选择
  4. Win32 API 声明(Declare 语句)清单 ── 按 API 的用途(打印、INI 文件读写、窗口操作等)分类，判断是否能用 .NET 的标准功能替代
  5. 只存在于代码中的业务规则 ── 尾数处理、截止日期、按客户区分的例外情况等。“没人知道为什么这么写”的地方，正是迁移后问题的温床
  6. 是否有测试手段 ── 要拿什么来比对确认迁移的正确性。多数情况下，与旧系统输出(报表、CSV、数据库内容)进行比对，是最实用的验证手段

即使最终没有选择全面重写，这项盘点也不会白费功夫。反而经常会因为盘点结果，发现“原以为需要全面重写，其实核心逻辑可以移到数据库端处理”“只要先迁移这 10 个界面，就能跨越 64bit 的高墙”这类分阶段迁移的切入点。

6. VB6 与 .NET 的主要不兼容之处

VB6 与 VB.NET/C# 之间的距离，远比名称给人的印象更远。无论是机械式转换还是人工重写，以下差异都必然需要设计判断。

领域 VB6 .NET 实务上的注意事项
错误处理 On Error GoTo / Resume 结构化异常(Try...Catch) 无法简单替换。需要确认原本“吞掉错误继续执行”部分的规格
类型 Variant、Integer 为 16bit 以静态类型为主，Integer 为 32bit 需梳理依赖隐式转换的代码。数值类型大小的差异是兼容性 bug 的常客
默认属性 如 Text1 = "abc" 的省略写法 已废除(需显式指定) 转换工具容易误判之处。要留意对象赋值与值赋值界限模糊的代码
数据访问 ADO / DAO / RDO ADO.NET 及之后版本 连接、事务、游标的概念完全不同。数据层应以“重新设计”而非“转换”为前提
界面 VB6 窗体＋OCX WinForms / WPF 控件并非一一对应。表格等 OCX 需要选定替代方案
打印・绘图 Printer 对象、窗体直接绘图 GDI+ / 打印 API 报表是迁移工时难以估算的领域。改用 Excel 输出报表也是一个选项
启动・分发 EXE＋运行时＋OCX 注册 也支持自包含式分发 能摆脱以注册表注册(regsvr32)为前提的运维方式，是迁移的优点之一

这里重要的是，不要被大量的不兼容之处压垮，就认定全面重写是唯一选项。反过来说，这张表左侧(VB6)的资产至今仍能正确运行这一事实本身，就是迁移时最好的规格书。让旧系统以“能运行的规格书”形式并行运行，一边比对输出一边推进，实务上是最可靠的做法。

7. 分阶段迁移的实务模式

若要在不中断业务的情况下进行迁移，新旧并存的架构就是关键所在。以下列举三种具有代表性的模式。

7.1 先迁移数据层

先将 VB6 应用的数据，从 Access 文件或私有格式迁移到 SQL Server 等数据库，VB6 端只切换连接目标继续运行。只要数据先完成现代化，新界面(.NET 端)就能引用同一个数据库，逐步增加。与 Access 相关的具体步骤，请参阅上一篇文章中“升级”的章节。

7.2 用 .NET 构建新功能・新界面，通过 COM 互操作连接

保留现有的 VB6 界面，用 .NET 构建新功能并让两者并存的架构。方向有两种。

  • 从 VB6 调用 .NET 端的组件：只要将 .NET 类以 COM 形式公开，VB6 端就能把它当作普通的 COM 组件来引用。关于即使在 .NET 8 以后也能以强类型方式公开的做法，我们在《用强类型方式从 VBA 调用 .NET 8 的 DLL ── dscom 与 TLB》中有详细说明，即使调用端是 VB6，思路也是一样的。
  • 从 .NET 调用 VB6 端的资产：用 VB6 编写的 ActiveX DLL，可以通过 COM 互操作从 .NET 端引用。适用于想整体保留原有逻辑、只先把界面 .NET 化的情况。不过 32bit 的限制仍然存在，因此应将其视为迁移期间的过渡桥梁，而非永久方案。

7.3 拆分进程进行集成

如果通过 COM 互操作让新旧共处于同一进程，位数(32bit/64bit)与故障波及范围就会成为制约。当需要 64bit 的新功能，或想把新旧故障隔离开时，可以拆分成不同进程，通过文件、命名管道、localhost 通信等方式集成。进程间集成的选项，我们整理在《Windows 的 IPC 判断表》中；32bit→64bit 桥接的实例，整理在《COM 桥接实例》中。

无论采用哪种模式，共同的原则都是“把新旧的边界集中到一处，并固定跨越边界的数据格式”。如果边界随界面或功能各自分散增加，并存期间的成本就会侵蚀迁移带来的效果。

8. 迁移目标语言 ── C# 还是 VB.NET

虽然“既然来自 VB6，选 VB.NET 比较自然”是普遍的想法，但结合当前 Microsoft 的语言战略来看，事情并没有那么简单。

在官方语言战略中，Visual Basic(VB.NET)被定位为“保持稳定设计、简单易懂又亲切的语言”，并明确表示新功能原则上仅限于消费端(consumption-only)、不新增语法，也不会扩展到新的工作负载。另一方面，对 Windows Forms、库等核心场景的投入，以及 Visual Studio 上开发体验的改进，仍会持续进行。3

从迁移的角度来解读，可以归纳如下。

  • 即使选择 VB.NET，现有场景(WinForms 业务应用)在可预见的未来仍能顺利运行。对于 VB6 经验者较多、语法相近能够降低学习成本的团队来说，是合理的选择。
  • 不过，作为今后新编写资产的基础，建议采用 C#。其语言与生态系统持续演进，示例、库、人才的供给也集中在 C# 上。这是为了避免十年后把“VB6 没有维护人力”的问题，重演为“VB.NET 没有维护人力”的问题而做出的选择。
  • 作为折中方案，也可以采用用 VB.NET 接收转换工具的输出，新开发则用 C# 编写的架构。在 .NET 中，两种语言的程序集可以相互引用，因此语言混用本身并不构成障碍。

界面框架的选择(WinForms / WPF / WinUI)请参阅《WinForms・WPF・WinUI 判断表》；若不迁移到 .NET Framework、而是直接迁移到现行 .NET，该确认的事项请参阅《.NET Framework→.NET 迁移前检查清单》。除非受限于所引用的库，否则从 VB6 迁移时，并没有特意新采用 .NET Framework 4.8 的理由。

9. 总结

  • “VB6 能用到什么时候”的答案是：运行时在 Windows 的支持期间内都属于运行对象(Windows 11 也包含在内)。不过 IDE 已于 2008 年终止支持，重建或修复的官方后盾早已不存在，这是一种不对称的状态。21
  • 真正的期限不是由操作系统决定的，而是取决于能修复的环境与人才是否还在。迁移计划应该趁旧系统还能当作“能运行的规格书”使用时就制定，而不是等故障发生之后再说。
  • 推进方式分为全面重写、自动转换、分阶段迁移三大类。在选定方式之前，应先对界面、外部集成、OCX、API 声明、只存在于代码中的业务规则进行盘点。
  • 在不中断业务的迁移中，可以通过数据层先行、COM 互操作、进程分离等方式之一让新旧并存，并把边界集中到一处。
  • 新编写部分的语言建议采用 C#。VB.NET 走稳定路线是官方方针3，作为长期维护的基础，C# 更具优势。

相关文章

相关咨询领域

合同会社小村软件(KomuraSoft LLC)提供包括 VB6 在内的存量资产盘点与迁移方针梳理、以 COM 桥接・进程分离进行新旧并存架构的设计与实现，以及向 .NET 迁移的分阶段替换服务。

参考链接

  1. Microsoft Learn，Visual Basic 6.0 Support Announcement。关于 VB6 IDE / Visual Studio 6.0 IDE 已于 2008 年 4 月 8 日终止支持、由于没有受支持的方式可以创建或维护 VB6 应用因而强烈建议改用现代技术、迁移时会提供升级指南与迁移合作伙伴等内容。 ↩ ↩2 ↩3

  2. Microsoft Learn，Support Statement for Visual Basic 6.0 on Windows。关于 VB6 运行时在搭载的 Windows 版本支持期间内属于支持对象、Windows 11・Windows 10・Windows Server 2025 等均包含在支持对象操作系统中、支持范围仅限于严重回归问题与重大安全问题、运行时仅支持 32bit 且在 64bit 操作系统上仅在 WOW 环境中受到支持、第三方制作的控件属于厂商责任范围等内容。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  3. Microsoft Learn，Annotated Visual Basic language strategy 与 Microsoft .NET language strategy。关于 Visual Basic 保持稳定设计、新功能以消费端(consumption-only)为主并避免新增语法、不会扩展到新的工作负载、对 Windows Forms 与库等核心场景以及 Visual Studio 体验的投入将持续进行等内容。 ↩ ↩2 ↩3

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

业务应用程序的日本年号・法定节假日・结算日处理 —— 抗改元设计与 JapaneseCalendar・营业日计算实务

报表要显示「令和8年」、营业日计算要排除法定节假日、20日结算次月末付款——日本业务应用程序特有的日期处理背后，隐藏着「日后会变动的规格」：改元、法定节假日的法规修订、月末的进位。本文整理了用 JapaneseCalendar 显示年号、抗改元的设计方式，法定节假日不可写死...

阅读文章

常见问题

汇总了咨询这一主题时常见的问题。

VB6 应用程序在 Windows 11 上还能运行吗？
属于支持范围。根据 Microsoft 的支持政策，VB6 运行时(msvbvm60.dll 等)只要搭载在仍处于支持期内的 Windows 版本上，就属于支持对象，支持对象操作系统列表中包含 Windows 11、Windows 10 和 Windows Server 2025 等。不过支持范围仅限于处理现有应用程序的严重回归问题与重大安全问题。此外 VB6 运行时仅支持 32bit，在 64bit Windows 上只在 WOW64 这一 32bit 兼容环境中受到支持。
从 VB6 迁移到 .NET，只靠自动转换工具就能完成吗？
应该假设无法完成。转换工具可以省去界面定义与简单逻辑改写的部分工作量，但诸如 On Error 错误处理、依赖 Variant 类型或默认属性的代码、ActiveX 控件、Win32 API 声明等，都需要人工进行设计判断与修正。不要把工具的输出直接投入生产环境，而应把「转换后由人工完成的收尾工时」也纳入整体估算，并事先确定验证转换结果的方法(例如并行运行或输出比对)。
迁移目标应该选 VB.NET 还是 C#？
新编写的部分建议采用 C#。Microsoft 的语言战略将 Visual Basic(VB.NET)定位为保持稳定设计的语言，并明确表示不会新增语法，也不会扩展到新的工作负载。对既有场景(如 Windows Forms)的投入仍会持续，所以 VB.NET 不会变得不可用，但作为未来十年要维护的代码基础，语言与生态系统持续演进的 C# 在人才储备方面更具优势。如果团队中 VB6 经验者较多，选择语法相近的 VB.NET 作为过渡也是一种可行做法。
在全面重写之前，应该先做什么？
应该在动手写代码之前先做资产盘点。具体来说包括：界面与报表清单、外部集成清单(数据库、文件、串口通信、其他系统)、正在引用的 OCX/ActiveX 控件与 COM 组件清单、Win32 API 声明(Declare 语句)清单，以及「只存在于代码中、没有规格书」的业务规则梳理。这项盘点的结果，往往会让人发现比起全面重写，只切出一部分进行分阶段迁移，或先迁移数据层，才是更务实的做法。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

联系我们
返回博客列表