VB.NetからVB6プログラムの読み出し

Visual Basic

昔は業務系システムの開発をVB6で行うことが多かったようで、VB6で作成されたシステムは世の中に数多く存在しているようです。

そのためか、システムの改修作業などで、今でもVB6で作成されたシステムに触れる機会は多いです。
私も、入社して最初に触れたのはVB6で作成されたシステムでした。

VB6は古い言語ではありますが、ものすごく扱いやすく開発効率が高いすばらしい言語だと思います。

しかし、VB6は開発における全てのニーズに応えてくれるわけではありません。

最近携わっている業務に、データ読込処理と、データ表示処理を同時に行う機能を追加するという話が上がりました。
言語はVB6です。

この機能をVB6で実現しようとしても、恐らくできないと思います。
VB6では複数の処理を同時に行うマルチスレッド処理が仕様上不可能だからです。

言語仕様の問題となると私のような平凡なプログラマでは手も足も出ません。

といっても簡単に「できない」で終わらせられないのが仕事です。
そこで考えた解決案がマルチスレッド処理を必要とする部分を別の言語でDLLとして作成し、そのDLLをVB6からキックさせるといった方法です。

しかしこの方法、
呼び出し元、呼び出し先の双方のプログラムが、.NetFrameworkで作成されていれば、言語間のやりとりの壁はほとんどないと思うのですが、片方がVB6で作成したプログラムであったため、言語間のやりとりがややこしくなります。


VB6のプログラムからVB.NetのDLLを呼び出す手段としてCOMというしくみに着目しました。
COMを使うことで、とりあえず、マルチスレッド処理を実現できたのですが、ここでまた新たな問題が発生します。

COMを通してプログラムを呼び出すためには、DLLの情報をレジストリに登録するという作業が必要になることです。

レジストリ登録の方法としては、.NetFrameworkがインストールされている環境でregasmコマンドを実行することで行えるのですが、エンドユーザへの配布を考えた場合、この作業はインストーラの機能に含め、自動化させなければなりません。

そもそも、VB.Netが絡んだ時点で、インストーラに.NetFrameworkのインストール機能を含めなくてはならず、インストーラの組み直しは避けられません。

こうなってくると色々と工程が増えそうで、追加機能の必要性を考えるとあまり現実的ではないという考えになってきます。

結局、この話はなくなり事なきを得ました。


プログラマあるいはシステムエンジニアは、「できる」「できない」の判断を迫られることが多々あります。

しかし、簡単にできそうなことが実はものすごく難しかったり、とてもできそうにないことが実はものすごく簡単にできたりと、プログラムの実現可否の瞬時の判断は一端のプログラマにしかできない芸当だと思います。

このことはしっかりと念頭に置いておかなければならない、
今回はそれを学びました。