Skip to content

MS_VB6Maintenance

Jump to bottom
nishi_74322014 edited this page Aug 31, 2026 · 1 revision

VB6の保守

概要

VB6 の保守関連情報。

詳細

Microsoftのサポート

状況

現段階で延長フェーズのサポートも切れており、
プレミア・サポート等を使用しても、VB 前提の開発上の問題は取り扱ってもらえない。
ただし、ランタイム・サポートはされているのでこの範囲のサポートを受けることは可能。

  • VB6 IDE
    2008/4/8 で延長サポートも切れている。

  • VB6 ランタイム
    ランタイム・サポート対象 OS では以下がサポートされる。

    • OS に同梱されているファイル
      主要なランタイム・ファイルは OS に同梱されており、
      OS のライフサイクルを通してサポートされる。
      TriEdit.dll（DHTML Editing Component と関連付けられるモジュール）
      は Windows Vista 以降のバージョンには同梱されていない。

    • アプリケーションと共に配布する拡張ファイル
      コントロールやライブラリ、ツールの拡張リストは
      ダウンロードセンターから入手して再頒布する必要がある。

    • サポート対象外のランタイム ファイル

      • 再頒布可能なランタイム ファイルとして同梱されていないファイルもある
        （古い VB4 または VB5 アプリケーションをサポートする目的で IDE メディアの
        \Tools フォルダに格納されていたファイルや、サードパーティのコントロールなど）。
      • これらのファイルが Vista で動作することは、
        アプリケーションの互換性と動作のテストを行った際に確認されているが、
        これはサポートとサービスに関するなんらかの保証を表すものではない。

  • 64 ビット Windows
    WOW64 エミュレーション環境でのみランタイム・サポートされる。

  • VBA

    • VBA のサポートには Office のサポート ポリシーが適用される。
    • VBA を使用して VB6 ランタイムを呼び出したり、ホストしたりすることもある。
    • そのような場合は、サポート対象の VBA 環境内で、OS に含まれているサポート対象の
      VB6 ランタイム ファイルと拡張ファイルを使用すれば、それらのファイルはサポートされる。

  • VBS

    • VBScript には、この VB6 のサポートに関する声明は適用されない。
    • VBScript は現在 Windows Vista、Windows Server 2008、
      および Windows 7 に同梱されているため、これらの OS の
      サポート ライフサイクルに応じたサポートの制限を受ける。

補足（最新化）: 本ページの記述以降の主な動きは次のとおり。

  • VB6 ランタイムは現在も「Windows のライフサイクルに従う」方針が維持されており、
    Windows 11 / Windows Server 2022 でも動作・サポートされる。
    この点で VB6 は「保守を続けられる」側の技術である。
  • 一方 VBScript は非推奨化され、Windows 11 では既定で無効化のうえ
    将来的に削除される予定が公表されている。
    本ページの言うとおり VBScript は VB6 とは別のライフサイクルであり、
    こちらは期限が切られた点が大きな違いになる。
  • VB6 IDE は Windows 10 / 11 上でも動作するが、サポートは無いため、
    保守を続ける場合は開発環境そのものを仮想環境で保全しておく運用が現実的
    （→ 仮想化塩漬け提案）。

参考

ミドル・ツール類

また、ミドル・ツール類のサポート問題もある。

サードパーティ製ミドル

UI コンポーネントなどの VB6 向けの種々の ActiveX コンポーネント製品が出荷されてきたが、
環境移行時は、これらが、各プラットフォームでサポートされるかの調査が重要になる。

移行メモ（正誤）: 元ページの見出し「サードパティ製ミドル」は
「サードパーティ製ミドル」の誤記と判断し、修正した。

補足（ここが VB6 保守の実際の限界）: 上記のとおり
VB6 ランタイム自体は動くので、保守が行き詰まるのは
ほぼこの 3RD パーティ製 OCX / ActiveX である。典型的には、

  • ベンダが廃業・製品終息していて、新 OS 用のビルドが出ない
  • 64bit 版が存在せず、64bit プロセスからは利用できない
  • ライセンス認証サーバが停止して、開発時のライセンスが通らない

といった形で顕在化する。
移行性評価作業でも指摘されているとおり、
使用コンポーネントの棚卸しを最優先で行うべき理由がここにある。

環境移行

VB6 アプリケーションの環境移行では移行性評価（互換性テスト）が重要になる。

  • Windows Vista、Windows Server 2008、およびWindows 7における Visual Basic 6.0 のサポートについて
    http://msdn.microsoft.com/ja-jp/vbasic/cc707268

    Windows Vista 、Windows Server 2008 および Windows 7
    でも引き続き Visual Basic 6.0 を使用する予定がある開発者は、
    それぞれ対象の Windows をインストールし、アプリケーションの受け入れテスト
    をしてアプリケーションの互換性テストに着手することをお勧めする。

VB6 アプリケーションの環境移行の注意点は、
環境移行ではあるものの、サポートされない VB 開発環境を使用する
必要があるため場合によっては手詰まりになる可能性がある事である。

このため、見積もり前に準委任契約等で
移行性評価（互換性テスト）を実施することが推奨される。

Windows8

Windows 8 でも VB6 ランタイムがサポートされるもよう。

Windows10

セルフ・サポート

  • 開発環境の更新が VB6 SP6 の stable な状態で無くなっており、
    インターネット上に多くの情報を確認できるということを考えると、
    （VBA などの現時点でも開発がサポートされるコードと言語仕様が同じであることも大きい）

  • 今後のセルフサポート可能と考えるが、新技術や移行対応、また、
    COM+ などの一般的ではない範囲の保守については一定の問題があると考える。

Webサービス（SOAP）

  • Microsoft SOAP Toolkit

    • 2.0
      2001 年以降更新されておらずサポートも切れているため
      最新の環境（SOAP の新規格）上では問題が発生する可能性がある。

    • 3.0
      3.0 は現在も保守され続けているが、
      フリーウェアであるため問題が発生した場合も、サポートされない。

    • WSDL でオブジェクトを生成するレイトバインド実装

      • メソッド一覧をインテリセンスで知ることはできない。
      • デバッガで型情報を確認することはできるかもしれない。

    • 参考

  • MSXML2.XMLHTTP
    代替案としては Web 参照などはできないが、MSXML2.XMLHTTP を使用するのが良い。

    • VB6 や VBA で HTTP 処理する際に使用できるコンポーネント。
      Ajax の XMLHttpRequest 実装の元となった IE の実装。

    • MSXML は WSDL を読み込む Web 参照ができないので、素組での実装が必要になる。
      また、MTOM（Streaming）などのクライアント機能を実装可能かの調査が必要になる。

    • 端末側（マクロ実行環境）に MSINET.OCX を配置できず、
      MSXML2.XMLHTTP を使用するといった事例もあるもよう。

    • 参考

補足（TLS のバージョンで詰まる）: MSXML2.XMLHTTP で HTTPS 通信を行う場合、
使用される TLS のバージョンは OS の設定（WinHTTP / SChannel）に依存する。
このため、サーバ側が TLS 1.2 以上のみを受け付ける構成に変わると、
VB6 側は一切変更していないのに通信できなくなるという形で問題が出る。
レジストリ（SecureProtocols など）で OS 側の既定を引き上げることで解決するが、
サーバ更改（バージョン・アップ移行）でも触れたとおり、
既定値の変更による障害の典型例として押さえておくとよい。

Webサービス（WebAPI）

Webサービス（SOAP）と同様に、MSXML2.XMLHTTP を使う。

IE上からホストされるActiveX

IE9 から（VBCOM の）ActiveX を呼び出す処理で問題が発生した事例がある。
VB6 ランタイムの問題、IE9 のサンドボックス化、Web アクセス、また、
その際のサーバ証明書の確認などに起因すると思われる問題が多発した。

移行メモ（正誤）: 元ページの「VB6ラインタイム」は「VB6 ランタイム」の誤記と判断し、修正した。

自己署名に対する警告や、失効確認時のプロキシ認証等の
ダイアログが表示されるため、以下に起因する問題と思われたが、

  • インターネット ・ エクスプローラー ・ 9 VB6 ActiveX コントロールによって
    起動されるモーダル ダイアログ ボックスを閉じると、web ページが応答を停止します。
    http://support.microsoft.com/kb/2534409/ja

ここに記載されている「セキュリティ更新プログラム」を適用しても現象は改善しなかった。

以下の情報よりレジストリを直接更新することで KB2534409 の現象が
回避できることは確認したが、サポートされない方法であるとのこと。

補足（IE の提供終了により、この構成自体が取れなくなった）: 本節は
IE 上でホストされる ActiveX を前提にしているが、
IE11 デスクトップ アプリは 2022 年 6 月に提供終了しており、
Edge の IE モードでも ActiveX の扱いには制約がある。
ブラウザ内で VB6 製 ActiveX を動かす構成は、
保守ではなく移行の対象として扱うべき段階にある
（→ IEバージョンアップ情報）。

MTS、COM+（Enterprise Service）

  • Windows NT 4.0 Service Pack 4 における MTS（1998）
  • Microsoft Windows 2000 における COM+（2000）

上記は、.NET 登場（2002）間近にリリースされた製品で、
まだ、Microsoft 系開発ツールを用いたサーバサイド開発が
一般的では無かった時期の技術であり、開発に採用された実績が少なく、
技術者（スキルセットを満たす人材）を集め難い等の問題を持っている。

提案

.NETへの移行提案

テクノロジ・カットでの提案だけでは弱い。

利用者のメリット

.NET での機能強化がユーザの利便性に繋がる所は
全般的に利用者のメリットに繋がると言えます。

  • 並列処理対応

    • 非同期呼び出しなど。

  • 最新アーキテクチャへの対応

    • Web
    • クラウド

  • 配布関連

    • Web
    • ClickOnce

  • リッチな画面を作りやすい UI サブシステム。

    • 国際化対応（支援機能）
    • WPF / Silverlight、HTML5
    • Video、Media 系
    • タッチ操作
    • また、そういう VB6 時代になかった
      サードパーティ UI コンポーネントが手に入る。

開発側のメリット

開発側のメリットは

  • サポートがある。
  • 開発支援機能の強化。
  • 開発要員を確保しやすい。

などです。

具体的には、

  • Microsoft のサポートを受けられる。

  • 各種開発支援機能が利用できる。

    • Unicode 対応
    • 国際化対応
    • Web サービス
    • .etc

  • 開発者（保守要員）がいなくなる可能性

    • COBOL と違って保守要員を抱えていないケースが多く開発者を確保しにくくなる。
    • オフショアが実用的になったころ VB6 新規開発は少なくなっていたので、人が集まるか？

  • 参考

補足（「利用者のメリット」で語るという主張について）: 本節の
「テクノロジ・カットでの提案だけでは弱い」という指摘は、現在も有効である。
移行の稟議は「動いているものをなぜ触るのか」という問いに答える必要があり、
サポート切れというリスク論だけでは決裁が通りにくい。
現在この文脈で使える追加の論点としては、

  • クラウド前提の業務システムとの連携（API 化、SaaS 連携）
  • 監査・セキュリティ要件（TLS、認証方式、ログ要件への追随）
  • リモートワーク前提の配布・実行形態

があり、いずれも「新しい要件が発生したときに VB6 では応じられない」
という形で説明できる。

仮想化塩漬け提案

VB6 保守の提案パスとしては、仮想化技術を使用し、
古い環境内に塩漬けにする方式も考えられる。

これにより環境移行にかかる諸費用を抑えることができる。

概要

  • 以下から選択できる。

    • OS レイヤで仮想化する
    • AP レイヤで仮想化する

  • 仮想化方式毎のトレードオフ

    • 互換性順（高 > 低）
      VDI ≒ MED-V ≒ XP Mode >>>>>>>>>>>>>>>>>>>>>>>>>>> ThinApp > App-V

      • 左辺が OS レイヤ、右辺が AP レイヤ
      • 当然、OS レイヤで仮想化する方が互換性は高い。

    • 価格順（高 > 安）
      VDI >>>>>>>> MED-V > App-V >>> ThinApp > XP Mode

      • AP レイヤより OS レイヤの仮想化の方が高価
      • XP Mode は OS レイヤの仮想化だが、7 に付属のため無償

    • （管理者から見た）便利さ順（便利 > 不便）
      VDI >>>> App-V > MED-V >> ThinApp >>>>>>>>>>>>>> XP Mode

  • 事例から最終候補は VDI になる可能性が高いと考えられる。以下その理由。

    • AP レイヤの仮想化では OS のレイヤ越えられない（互換性が低い）。
    • 対象クライアント数が多いと管理の難しい XP Mode は困難。
    • MED-V はクライアント要件（VT ＆大容量メモリ）の敷居が高い。

  • なお、VB6 の塩漬けだけと考えると高価になるが、
    情シスの管理工数削減やセキュリティ向上の効果も狙えるので、
    そちらに誘導することで受注につながる可能性がある。

補足（挙げられている製品の現況）: XP Mode は Windows 7 限定の機能で、
MED-V / App-V / ThinApp もそれぞれ提供が終息、または位置づけが変わっている。
現在同じ目的で採れる選択肢は、

  • VDI（Azure Virtual Desktop、Windows 365 など）— 本ページの結論どおり本命
  • ターミナルサービス系への移行（RDS）
  • P2V して Hyper-V 上で隔離運用
  • MSIX（App-V の後継にあたるアプリ仮想化・パッケージング）

となる。**「AP レイヤの仮想化では OS のレイヤを越えられない」**という
本ページの判断基準は、製品が入れ替わった現在でもそのまま使える。

注意点

  • OS 含め仮想化しても、古い OS を動かせるかどうかの問題も出ます。

    • P2V・仮想環境のプラットフォーム、ミドル、ツールも、ゲスト OS に合わせた古いものが必要。
      （最新の P2V・仮想環境の製品は、古すぎるゲスト OS に対応しない）

    • 古さによっては、P2V・仮想環境の製品、ゲスト OS の古い環境が入手できない場合もあります。

  • サポート切れOSの延命処置

移行メモ（正誤）: 元ページの「合わせてた古いもの」は
「合わせた古いもの」の誤記と判断し、修正した。

参考資料

VC++化

VC++ での COM 呼び出し（IDispatch）の書き方が解ると楽。
Office オートメーションのコードを移植する場合にも活用できる。

参考

通信ライブラリ

Microsoft SOAP Toolkit

MSXML2.XMLHTTP

本 Wiki 内

Tags: 移行, Visual Basic

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally