■VB5.0→6.0

　ここには、Visual Basic 5.0 で開発したアプリケーションソフトウェア資産 (ソースプログラムなど) を Visual Basic 6.0 用のものに移行させる手順、および両方の Visual Basic に対応できるようにする共通開発の方法が書いてあります。なお、Visual Basic 5.0 と MANDALA を併用して開発したソフトウェア資産の移行の手順、および共通開発の方法については、以下に説明があるものと基本的に同じですが､「MANDALA入門コースの手引き」に詳しい説明があります。

　ここでは、Visual Basic 6.0 がインストールされていることを前提にした説明になっています。ですから、まず Visual Basic 6.0 をインストールしてください。この際に、共通開発を目指すのであれば、Visual Basic 5.0 をインストールした OS の上に Visual Basic 6.0 をインストールしないようにしてください (同じ OS の上に無理やりインストールすると Visual Basic 5.0 が正しく動作しなくなると考えられます)。ですから、Visual Basic 5.0 と Visual Basic 6.0 は、別のパソコン (正確には別の OS) にインストールしなければなりません。そして、共通開発を目指すのであれば、両方の Visual Basic から参照できるところにソフトウェア資産を配置することが必要です。

　なお、共通開発を目指さず、以後一切 Visual Basic 5.0 を用いないと決意した場合には、Visual Basic 5.0 がインストールされていたパソコン (OS) に Visual Basic 6.0 をインストールしてもかまいません。この場合は、Visual Basic 5.0 をアンインストールしてから Visual Basic 6.0 をインストールすることをお勧めいたします。

　以下の手順に従うと、Visual Basic 5.0 で開発したアプリケーションソフトウェア資産を Visual Basic 6.0 用のものに移行させることができます。Visual Basic 5.0 から Visual Basic 6.0 へは、基本的に上位方向の互換性があるので移行作業は極めて簡単です。ですから、取りたてて移行作業と呼ぶような大袈裟な作業ではありません。

　Visual Basic 5.0 と Visual Basic 6.0 では、フォームモジュールやコードモジュールの形式が全く同じですから、これらを変換する必要はありません。しかし、プロジェクトファイルの形式が少しばかり変更されています。ですから、移行作業とは Visual Basic 6.0 用のプロジェクトファイルを作り出すことに他なりません。

　旧プロジェクトを Visual Basic 6.0 で開いてください。この操作をするだけで、旧プロジェクトファイルを新形式に変換することができます。

　名前を付けてプロジェクトの保存という指示を与えて新形式のプロジェクトファイルを新たなファイルとして保存してください。新しいプロジェクトファイルの名前は Visual Basic 5.0 用のプロジェクトファイルと同じにして、別のフォルダに保存することをお勧めいたします。

　この操作によって、Visual Basic 6.0 用の新たなプロジェクトファイルを作り出すことができるので、これで移行作業は完了となります。

　共通開発を目指す場合の注意事項ですが、新たなプロジェクトファイルは Visual Basic 5.0 用のプロジェクトファイルの上に絶対に上書きしないようにしてください。共通開発を行うには、Visual Basic 5.0 用のプロジェクトファイルと Visual Basic 6.0 用のプロジェクトファイルの二つが必要になります。そして、上書きしてしまうと、Visual Basic 6.0 用のプロジェクトファイルから Visual Basic 5.0 用のプロジェクトファイルを復元することは面倒です。

　なお、上書きさえしなければ、上記の移行作業を行っても、Visual Basic 5.0 用のプロジェクトファイルは、何の変更もされずに残ることになります。

　共通開発を目指さず、以後 Visual Basic 5.0 を用いることなどあり得ない場合に限っては、新たなプロジェクトファイルの内容を Visual Basic 5.0 用のプロジェクトファイルの上に上書きしてしまってもかまいません。

　ここには、Visual Basic 5.0 と Visual Basic 6.0 の両方に対応できるようにする共通開発の方法が書いてあります。近未来に、両方の Visual Basic を使わなければならないような事態が少しでも予想される場合には、ソフトウェア資産を両方の Visual Basic に対応したものにするのがよいでしょう。

　Visual Basic 5.0 と Visual Basic 6.0 では、フォームモジュールやコードモジュールの形式が全く同じです。ですから、Visual Basic 5.0 で開発したソースプログラムと Visual Basic 6.0 用のソースプログラムを別々にもつことは効率的ではありません。なぜなら、ソースプログラムを別立てにすると、変更が必要になった際に両方のソースプログラムに対して同じように手を入れなければならなくなるからです。これらを共通のソースソースプログラムにしておけば、変更は一回で済みます。

　共通のソースソースプログラムとして管理するには、二つの OS のどちらからも参照できるところにソフトウェア資産を置くことが必要になります。なぜなら、前述のように Visual Basic 5.0 と Visual Basic 6.0 を同じ OS の上にインストールすることはできません (無理にインストールすると Visual Basic 5.0 が正しく動作しなくなると考えられます)。ですから、Visual Basic 5.0 と Visual Basic 6.0 は、別のパソコン (正確には別の OS) にインストールしなければなりません。したがって、Visual Basic 5.0 と Visual Basic 6.0 の両方から使うソフトウェア資産は二つの OS のどちらからも参照できるようにしなければなりません。

　このように両方から参照できるようにするには、例えば、ソフトウェア資産を LAN で結ばれたサーバ上のファイルにするのは一法です。あるいはデュアルブートの (二つの OS のどちらを使うのかを OS のロードの際に切り替えられるように設定した) パソコンの上にソフトウェア資産を置くのもよいでしょう。

　このような手段を用いて、フォームモジュールやコードモジュールは、二つの Visual Basic のどちらからも参照できるところに置かなければなりません。しかし、プロジェクトファイルについては必ずしもこうする必要はありません。プロジェクトファイルについては、Visual Basic 5.0 用と Visual Basic 6.0 用の二つを別々に用いることになります。

　そして、図のように二つのプロジェクトファイルから共通のフォームモジュールやコードモジュールを指し示す (ポイントする) ようにします (前述の移行の手順に従えば、自然にこうなります)。こうしておけば、一方の Visual Basic で共通のフォームモジュールやコードモジュールに対する変更を行うと (そして保存すると)、もう一方の Visual Basic でそれらを参照したときに変更されたものが見えるようになります。即ち、変更は一回で済むことになります。

　しかし、一方の Visual Basic で、あるプロジェクトにモジュールの追加や削除を行った場合には、もう一方でも同じことを行うことが必要です。プロジェクトファイルは共通化することができないので、これに関する変更は一回では済まずに、それぞれの Visual Basic で行うことが必要だということです。

このような共通開発をなさる場合の注意事項ですが、それぞれの Visual Basic で一応テストを行うことをお勧めいたします。こう申しましたが、一方の Visual Basic できちんとテストをなさっておけば、もう一方の Visual Basic ではテストを軽くすませることができると言ってよいかもしれません。

　Visual Basic 5.0 と Visual Basic 6.0 とでプログラムの内容を変えなければならないことは、一般にはほとんどありません。しかし、そうしたことが必要になった場合には、条件付きコンパイル機能を活用すればよいでしょう。即ち、以下のようにプログラムを書けばよいでしょう。

　このように条件付きコンパイル機能を使う場合には、VbVersion の指定を各プロジェクトごとに行ってください。即ち、ﾌﾟﾛｼﾞｪｸﾄﾌﾟﾛﾊﾟﾃｨというダイアログボックスの実行可能ﾌｧｲﾙの作成というタブの中の条件付きｺﾝﾊﾟｲﾙ引数(D): として VbVersion = 5 または VbVersion = 6 と指定してください。因みに、この指定情報は Visual Basic 5.0 用と 6.0 用のそれぞれのプロジェクトファイルに格納されます。

　ブラウザの戻る (Go Back) のボタンを押して元に戻るか、目次のページに戻ってまだご覧になっていないところに進んでください。あるいは、付録２をまだご覧になっていなければ、付録２に進んでください。

　マイクロソフトは今年末に開発環境の新製品「Visual Studio 2005」の出荷を始める見込みだ。すでにベータ版（日本語ベータ2）がダウンロードできるようになっているので試した方も多いと思う。

　実際に使ってみると，良くできていると感じる。例えば，コード片の再利用を援助する「コード・スニペット」や，リファクタリングを支援する機能などはとても便利だと感じた。また，「エディット・コンティニュー」も生産性を上げてくれるだろう。

　良くできていると感じると同時に，「Visual Basic（VB）ユーザー，特にVB 6.0ユーザーにずいぶんと気を遣っているな」とも感じた。それほど，VBの機能拡張が目立つ。

　その最たる例がMyクラスだ。これは，VBのためだけに用意したクラスで，.NET Frameworkが提供する機能の中から，VBユーザーがよく使いそうなものをコンパクトに再構成したものだ。「My」というクラスを基底クラスとしているので，どの機能を使うにしても取りあえずMy以下を探せばよい。

　前バージョンまでは，広大な.NET Frameworkのあちこちを探し回らなければならなかった局面でも，Myクラスを利用すればかなり省力化できる。Visual Studioが備えるIntelliSense（※1）を利用すれば，もっと便利に使える。取りあえず「My」と打ち込んでおけば目的のメソッドやフィールドを探していける。

　また，フォームへアクセスするコードを書くときに，宣言する必要がなくなった点もVB 6.0ユーザーへの配慮だ。VB 6.0と同じようにインスタンス化（※2）せずにフォームにアクセスできるようになったのだ。しかし，このような仕様変更は，すでに.NETに移行した人から見るとおかしなものに映るだろう。オブジェクト指向の考え方からすると，インスタンス化せずにフォームにいきなりアクセスできるということはおかしいからだ。

　また，私はMyクラスにも疑問を感じる。使ってみると確かに便利だが，VBユーザーのためだけにここまでする必要があるのだろうかと思った。.NET Frameworkですでに実現している機能を，他のクラスでまとめ直す必要があるだろうか。こういうことをしていると.NET Framework全体の複雑化につながりはしないかと心配になる。

　マイクロソフトがここまでする理由はただ一つ。とにかくVB 6.0ユーザーを.NET Frameworkに移行させたいと考えているからだろう。マイクロソフトはVB 6.0の後継としてVB .NETを投入したが，VB 6.0のユーザーはオブジェクト指向を本格的に採り入れたVB .NETの言語仕様に戸惑い，なかなか移行しようとしなかった。また，プログラム部品の基盤が.NET Frameworkに変わったことも，VB 6.0ユーザーを困らせた。基盤が全く変わって，必要な機能がどこにあるのかが分からなくなってしまったのだ。

　厳しい方なら「勉強して新しい環境に適応すべきだ」とおっしゃると思う。しかし，当面の仕事を片づけることが最優先になってしまうとなかなかそうも言えなくなる。このような事情から，VB 6.0を使い続けるユーザーも多い。しかし，いつまでもVB 6.0を使い続けるわけにはいかない。マイクロソフトは2005年3月31日にVB 6.0のメインストリーム・サポートを打ち切っている。ここから先は延長サポート期間となり，修正プログラムも有料になる。

　このようなマイクロソフトの方針に反発して，サポート延長，あるいはVB 6.0に近い形の新しいVBを求めるユーザーもいるが，そんなことが現実になるとは思わない方がよい。もはや後戻りはできないのだ。VS .NETが登場してから3年が経ち，.NET Framework上でアプリケーション開発をする人も増えてきた。いよいよ.NET Frameworkの本格的な普及が始まったのだ。

　そこで登場するVB 2005は，VB 6.0ユーザーに配慮した新機能を搭載している。.NET Frameworkにすでに移行した人から見ると奇異に映る機能を思い切って搭載してきたのは，VB 6.0ユーザーへの最大の配慮と言っていいだろう。世間では.NET Frameworkが着実に普及している。VB 6.0ユーザーが.NET Frameworkに移行するならVB 2005が最大のチャンスとなるはずだ。

　それでもオブジェクト指向に拒否反応を示して移行をためらう人もいるかもしれない。しかし，よく考えてみてほしい。現在広く普及しているプログラミング言語で，オブジェクト指向を採り入れていない言語がどれだけあるだろうか。つまり，今やプログラマにとってオブジェクト指向は必修科目なのだ。

※2　インスタンス化：　オブジェクト指向プログラミングで、クラスを基にした実際の値としてのデータのこと。クラスと対比して用いられることが多く、クラスを「型」、インスタンスを「実体」として説明されることもある。

　「オブジェクト」とほぼ同義語のように用いられることが多いが、実際にメモリ上に配置されたデータの集合という意味合いが強く、データの実体をより具体的・直接的に捕らえた用語である。