小村軟體有限公司
聯絡我們
選單

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 支援期間內」屬於支援對象。對象 OS 清單中包含 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 等搭載於 OS 中的執行基礎 搭載的 Windows 支援期間內受到支援
執行環境擴充檔案 主要 OCX 控制項類(隨應用程式一併重新散布) 同上(須由應用程式端負責散布)

對象 OS 清單中，Windows 11、Windows 10、Windows Server 2012～2025 均明確標示為「執行環境：支援」「IDE：不支援」。2

解讀時有三個重點。

第一，執行環境的支援完全從屬於 Windows 的生命週期。並不存在「VB6 執行環境支援截止日」這種獨立日期，所使用 Windows 的支援結束日就是期限本身。

第二，支援的實質內容比較接近「維持運作」的保證。受理的僅限於嚴重回歸(因 OS 更新導致既有應用程式損壞)與重大安全性問題，不包含個別調查或功能改善。2

第三，VB6 應用程式今後也只能以 32bit 行程的形式存續。執行環境僅支援 32bit，在 64bit OS 上只在 WOW64 模擬環境中受到支援。2 一旦出現需要與 64bit 專用 DLL 或 SDK 整合的需求，單一行程就無法獨力完成任務。跨越這道牆的方法，我們在「從 32bit 應用程式呼叫 64bit DLL 的 COM 橋接實例」中有詳細說明。

3. 「能運作」與「能維護」是兩回事

只看支援政策，可能會覺得「不需要著急」。但在實務上，開發與維護環境往往比執行環境更早崩壞。

  • 無法準備 IDE。VB6 IDE 在現行 OS 上不屬於支援對象，正式的取得手段與安裝手段一年比一年難以維持。「公司內只剩一台能修改的機器」這種狀態並不罕見。
  • 第三方 OCX 的廠商支援已經中斷。支援政策本身也明確指出，第三方製作的控制項屬於廠商的責任範圍。2 表格或報表用的 OCX 已經無法取得的案例相當多，這項判斷可以直接套用「ActiveX / OCX 現在該如何處理」中整理的內容。
  • 會寫程式的人消失了。這不是語言規格的問題，而是人的問題。幾乎沒有新的技術人員在學習 VB6，因此能維護的人數只會單調遞減。
  • 周邊需求撞上 32bit 的牆。新的設備 SDK、驗證函式庫、雲端整合等，逐漸以 64bit 與 .NET 為前提，無法納入 VB6 行程的需求越來越多。

也就是說，「能用到什麼時候」只是問題的一半。另一半是「下次需要修復時，是否還留有能修復的體制」。遷移計畫不該等到故障發生之後才制定，而應該趁還有能修復的人與環境時就先規劃。

4. 遷移方式的判斷表

即使決定「取代」，實際做法仍有多種。以下整理主要的幾種方式。

方式 概要 適合的情況 主要風險
全面重寫 重新整理規格，以 .NET 全新建構 畫面數量少 / 想重新檢視業務流程本身 / 規格可以說明清楚 隱藏的業務規則遺漏、並行開發期間拉長
自動轉換工具 用轉換工具將 VB6 程式碼機械式轉換為 .NET 程式碼，再由人力完成收尾 程式碼量大，想保留原有邏輯 / 不改變畫面配置 轉換後程式碼的品質與可讀性、最終仍會殘留的人工作業、工具費用
階段性遷移(絞殺者模式) 以功能為單位切出，讓新舊並存並依序取代 業務無法中斷 / 畫面與功能眾多 / 想分散風險 新舊並存期間的複雜度、邊界(整合部分)的設計能力要求高
維持現狀＋文件化 不遷移，透過固定環境、備份、文件化來延長壽命 幾乎沒有變更需求 / 可以固定機器與 OS 前一章的風險並未解除(只是往後延)

該選擇哪一種，並非光看程式碼行數就能決定。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 需梳理依賴隱含轉換的程式碼。數值型別大小的差異是相容性錯誤的常客
預設屬性 如 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
  • 真正的期限不是由 OS 決定，而是取決於能修復的環境與人才是否還在。遷移計畫應該趁舊系統還能當作「會動的規格書」使用時就制定，而不是等故障發生之後。
  • 推進方式分為全面重寫、自動轉換、階段性遷移三大系統。在選定方式之前，應先對畫面、外部整合、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 等皆包含於對象 OS、支援範圍僅限於嚴重回歸問題與重大安全性問題、執行環境僅支援 32bit 且在 64bit OS 上僅在 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 版本，就屬於支援對象，對象 OS 清單中包含 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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽