Visual Basic 6.0(VB6.0)は、長年企業活動を支えてきたプログラミング言語ですが、新世代であるVisual Basic.NET(VB.NET)が登場したことで、各企業では移行も進められています。基本的には同じ言語の両者ですが、VB.NETへの移行によって、そもそもどのような利点が期待できるのでしょうか。今回は、VB.NETへの移行を検討しているVB6.0ユーザーに向けて、マイグレーションのメリットや移行時のポイントについて、ご紹介します。
Visual Basic6.0とVisual Basic.NETの違い
Visual Basic6.0とVisual Basic.NETの違いについては、大小を問わず様々なポイントが存在します。
Visual Basic 6.0（VB6.0）を継続するリスクとマイグレーションのメリット
まずは使って体験
.NETの違いについていち早く理解するために、最も有効なのは実際にインストールして、まずは使ってみることです。
フォームにコントロールを貼り付けるとコードが生成されたり、フォームにClassというキーワードが付いていたり、VBフォームではなくWindowsフォームになっていたりと、視覚的にもその違いに気づけます。
ただ、一方で6.0から変わっていない部分も多く残されており、シンプルにその利便性の向上に満足できることが期待できます。
また、Visual Basic .NETとVisual Basic 6.0は共存できるよう設計されているため、現在と同じマシンで活用が可能です。導入に際しては大きな負担も発生しないため、試してみる価値は高いと言えます。
あらゆる言語に対応
そして、.NET Frameworkは何と20種類以上もの言語に対応している点も特徴です。C#、C++、Javaなど、Microsoft言語だけでもこれらを含めて5の言語に対応しています。
このような汎用性の拡張により、開発者は言語のアドバンテージに左右されることなく、自分が使いやすい、慣れ親しんだ言語で自由に開発を進められるようになったのです。
言語に左右されない環境を構築し、豊富なプログラマに好まれるよう現場を改革可能です。
アップグレードウィザードの活用
Visual Basic 6.0で手掛けていたプロジェクトは、ツールを活用して.NET向けにアップグレードが可能です。
手動でのアップグレードはもちろんですが、Visual Basic.NETを利用して6.0のプロジェクトを開くと、自動的にウィザードが起動してプロジェクトをアップグレードしてくれます。
対応しているのは6.0以降のプロジェクトのみということで、それ以前のプロジェクトを開きたい場合には、まず6.0のバージョンにアップグレードする必要がある点に注意しましょう。
Visual Basic.NETの利点
実際にVisual Basic.NETへ移行したことで、どのようなメリットを得られるのかについて、一つずつ見ていきましょう。
Visual Basic.NETの利点
エラーの少ない､よりよいコードが書ける
一つ目の利点は、エラーの少ない､よりよいコードが書けるようになる点です。従来よりも厳密なタイプチェック機能を有しているため、安定したコーディングの実現に役立ちます。
その結果、エラーを吐き出すリスクを抑え、より堅牢なアプリケーションの構築を実現できます。バグの入り込みにくいコーディングで、パフォーマンスの改善が見込めます。
オブジェクト指向のサポート
オブジェクト指向のサポート強化も、.NETの特徴です。オブジェクト指向に基づいて設計されたシステムの実装が容易になり、これまで実現できなかったプロジェクトの遂行も実現します。
.NET Frameworkへのフルアクセス
.NETへの移行によって、NET Frameworkへのフルアクセスが実現する点も捨てがたいところです。
WindowsフォームやASP.NET（Webフォーム、XML Webサービス）、ADO.NETなどの新しい機能を使えるようになるため、大幅な環境の改善に役立ちます。
これまでWindows APIを利用しなければ解決できなかった問題も、.NET Frameworkが提供する機能によって対応できるようになります。Windows APIの呼び出しに手を焼いていた開発者にとって、大きな改善ポイントとなるはずです。
開発環境の改良
6.0に比べて、開発環境の改良にもつながっているのは大きなポイントです。タスクリストではコーディング中に自動構文チェッカーがミスをチェックし、構文ミスの部分には波線でユーザーにミスを指摘し、リアルタイムでの修正を促します。
新たに追加されたダイナミックヘルプ機能では、動的なヘルプを提供します。
コーディング中には、テキストカーソルの位置にあるコードに関するヘルプを、フォームのデザイン中は、今アクティブになっているオブジェクトに関するヘルプを提供してくれるなど、スムーズな作業を促進します。
生産性を向上させるための機能にも優れているため、.NETへの移行で業務の効率化を進められます。
DLL Hellの解消
DLL Hellとは、DLLのバージョンアップによって前バージョンを活用していたアプリが動かなくなったり、この事態を回避するために複数バージョンのDLLファイルを構築し、同じようなDLLが大量に作成されてしまったりする事態を指します。
.NET Frameworkでは「プライベートDLL」という、DLLをそれぞれのフォルダへ適切に配置する手法を採用し、DLL Hellの発生を防止します。バージョンポリシーを利用して、そのDLLの最新のバージョンを利用するように指定することができるため、余計な混乱を未然に防ぎます。
容易なデプロイメント
Visual Basic 6.0で作成したアプリを配布する場合、ディストリビューションウィザードや市販のインストーラ作成ツールを使ってインストーラを作成していました。
しかし.NET Frameworkを活用することで、このようなデプロイメントの手間を省くことが実現します。
XCOPYによるデプロイメントや、Visual Studio .NETによるデプロイメントを実現し、作業効率化を推進します。
スムーズな移行のためのポイント：アーキテクチャ編
ここからは、スムーズな移行のためのポイントを詳細に見ていきましょう。まずはアーキテクチャのポイントです。
Windowsアプリケーション
まずはWindowsアプリケーションが、こちらはWindowsフォームをベースに作成します。WindowsコントロールやGDI+を利用してUIを整え、.NETコンポーネントやXML Webサービスの利用も可能な仕組みを備えます。
ActiveXコントロールなど、従来のCOMコンポーネントも利用できますが、.NETとの相互運用には限界もあるため、その点は考慮する必要があるでしょう。
このため、Windowsアプリケーションの運用については、.NETへのアップグレード後も6.0と対して変わらない使い方が可能です。
ウィザードを利用して容易にVisual Basic .NETへアップグレードができるため、COMコンポーネントなどを利用して、ユーザーインターフェイスとビジネスロジックをある程度分けておくだけで利便性を確保できます。
これらを分類しておけば、プログラムの置き換えなどへ柔軟に対応できます。
Webアプリケーション
Webアプリケーションの開発においては、Webフォームを利用することができます。
Webフォームには「HTMLベースのユーザーインターフェイス定義」と「イベント処理などのロジック」が含まれており、開発者は慣れた開発環境と言語を使い、Webアプリ開発を進められます。
また、ASP.NETでWebアプリケーションのプロジェクトを作成すると、事前に「WebForm1.aspx」と「WebForm1.aspx.vb」が作成されます。サーバーベースのアーキテクチャを採用し、イベントプロシージャを実装する感覚でデザインできるようにもなります。
ASP.NETの利用にはVisual Basicのアプリ開発のノウハウだけでなく、Webの開発知識も必要になってくるため、運用には知識と経験が必要です。しかしそれでも、運用を実現するメリットは大きいため、この条件に適合する人材を確保しておく意義は大きいと言えます。
コンポーネント
上の方でも少し触れましたが、Visual Basic .NETではCOMコンポーネントに代わり、.NETコンポーネントを作成できるようになっています。
.NETコンポーネントを作成する場合、「クラスライブラリ」、あるいは「Windowsコントロールライブラリ」をテンプレートとしてプロジェクトを作成する必要があります。
6.0で作成した「ActiveX DLL/EXE」プロジェクトは、.NETの「クラスライブラリ」に自動で変換されます。トランザクションの設定など、属性としてコードに含めるようになったものについては、手動での変換が求められる点に注意しましょう。
また、ユーザーコントロールのプロジェクトはアップグレードができません。変更を加えたい場合、6.0を使ってCOMと.NETの相互運用機能を活用するか、Visual Basic .NETでコントロールを新しく作り直す必要があります。
データアクセス
Visual Basic .NETでは、.NET Frameworkが提供するデータアクセスのためのライブラリであるADO.NETが利用可能です。
ADO.NETは分散アプリケーションに適したモデルで、分散化が進むアプリケーション開発において、企業を超えた規模の大きなアプリ開発の現場において強みを発揮してくれます。
合わせてXMLの機能も強化されており、XMLへの対応力が向上しています。分散アプリケーションで使用したときのパフォーマンスもADOと比べて向上し、ユーザビリティが改善しています。
DAO、RDOを利用しているVisual Basic 6.0のプロジェクトをアップグレードした場合、ラッパークラスが自動的に生成され、動作可能なアプリに変換されます。特別なコードは必要としないので、扱いやすさだけが強化されます。
ただ、データへのアプローチやアプリケーション設計の方針については、ADOとADO.NETでは違いが見られるため、互換性が完全にあるとは言い難いです。
そのため、ADOアプリケーションはADO.NET向けに初めから構築し直したほうが、後の利便性を考えると効率的であると言えるでしょう。
ADOとADO.NETのパフォーマンスを比較し、その優位性についても理解を深めておくのがおすすめです。
スムーズな移行のためのポイント：プログラミング編
ここからは、スムーズな移行を実現するための、プログラミングにおけるポイントをご紹介します。
変数宣言の変更
変数宣言の変更については、まず変数宣言を強制するために、Option Explicit Onを利用することとなりました。
そして、また、Visual Basic .NETでは「Option Explicit On」がデフォルトとなっているため、変数宣言を強制されたくない場合はOption Explicit Offと、ソースコードに記述する必要があります。
また、変数宣言の際の型指定にはDim x, y, z As Stringが使われます。これは、6.0における2つのVariant型データ（xとy）と、ひとつのString型データ（z）の生成を意味します。
6.0においても、変数は適切なデータ型を指定して宣言することが推奨されていました。.NETでは、Option Explicit Onがデフォルトになるため、6.0の段階から適切なデータ型を指定しておけば、Visual Basic .NETでの変更を最小限に済ませられます。
オブジェクト型への対応
.NETにおいては、IntegerやStringなど、基本データを含むすべての変数がオブジェクトとなっています。
型を指定しない変数のデータ型もObjectとなっているため、安全性や、他の.NET言語との互換性が高まるだけでなく、変数の持つ便利なメソッドやプロパティも利用可能となっています。
直感的で安全なプログラミングを実現できるため、その違いによる恩恵は大きいはずです。
変更に際しては、アップグレードウィザードが自動的に対応してくれるので、変数宣言をした整数の利用が行き届いていれば問題はありません。
Short・Integer・Longの整数データ変更
Short・Integer・Longの整数データは、それぞれ変更が加えられています。
具体的には、Shortは16ビット、Integerは32ビット、Longは64ビットとなりますが、アップグレードウィザードによって大きさが同じのデータ型に対応されるので、心配は無用です。
32ビットCPUでの最適化を図るためにLongを使っていた場合には、Integerへの変換が必要になりますが、これもアップグレードウィザードが自動的に対処してくれます。
この変更により、SQL Serverのデータ型と同じ大きさになったため、バグの発生率も抑えられるようになりました。
デフォルトプロパティが不要に
.NETへの移行により、デフォルトプロパティは使えなくなりました。これは、使えなくなったというよりも、デフォルトプロパティの必要がなくなった事が背景として挙げられます。
アップグレードウィザードは、デフォルトプロパティを自動解決し、.NETに最適化して変換してくれるため、わざわざ手動で書き換える必要はありません。
ただ、変数をObject型として宣言し、実行時にクラスのインスタンスを代入する実行時バインディングはオブジェクトが特定できず、自動変換も行えません。
コードの手動変更が必要になるため、オブジェクト変数の実行時バインディングは6.0の時点で避けておくことをお勧めします。
プロパティの変更
いくつかのプロパティについては変更点が見られますが、大きな変化はフォームやラベルコントロールの文字列を設定するCaptionプロパティが、Textプロパティへ移行した点です。
また、リストボックスやコンボボックスコントロールのListIndexプロパティがSelectedIndexプロパティに変更されるなど、他の.NET言語とプロパティ名を揃えるための対応が行われています。
アップグレードウィザードによって、これらの変更についても対応が自動で行われるため、安心して利用ができます。
配列のインデックスは0スタート
Visual Basic .NETでは、他の.NET言語との相互利用性を重視し、インデックスの下限は0からスタートすることとなりました。
この結果、Option Baseステートメントによってあらかじめ下限を指定する必要もなくなっています。
固定長文字列のサポート終了
固定長文字列については、.NETにおいてサポートが終了しています。というのも、配列と同様に他の .NET言語との互換性を確保するためというのが理由です。
アップグレードウィザードによって、固定長文字列は、Visual Basic固有の「VB互換文字列（固定長）」へと変換されます。
また、固定長文字列の変更もできなくなり、構造体の中の配列の指定についても未対応となります。
Dim x As New MyClassの動作変更
.NETにおいては、Dim x As New MyClassの動作に変更が加えられています。6.0では、このコードがある行ではオブジェクトは生成されず、利用の際にオブジェクトが作られているかを事前に確認することが必要でした。
Dim x As New MyClassはオブジェクトの存在を必ず確認するため、パフォーマンスの品質を維持する上では重要な機能です。
しかし、幾度のチェックを必要とするため、明示的なオブジェクト管理を阻害する要因となっている、というデメリットも懸念されています。
そのため、.NETにおいては毎度のチェックは排除されており、運用の利便性については向上がみられることとなりました。
アップグレードウィザードによって、6.0のプロジェクトにおけるコードが.NET環境ではいきなり変更されている、ということはなく、そのままのコードが維持されています。
ただ、その意味については.NET環境に準拠しているため、再度確認が必要です。Dim x As New MyClassを用いる場合、オブジェクト確認の必要性から挿入していることがほとんどですが、.NETにおいてはその確認が発生しません。
そのため、.NET環境では異なるプロセスによって、確認作業を挟む必要があるということは覚えておきましょう。
VB定数の変更
Visual Basic の組み込み定数であるVB定数では、名前と値の多くが変更されました。「vb~」ではじまる基準は撤廃され、他の言語と共通のオブジェクトへとアップデートされています。
アップグレードウィザードは、これらの値を全て最新のものに差し替えてくれます。
プロシージャの変更点
プロシージャについては、引数のデフォルトがByValへと変更されています。
また、プロシージャに対してStaticキーワードを指定することはできなくなり、Static変数にしたいときは、変数宣言時に個別で変換することとなります。
プロパティプロシージャの変更点
プロパティプロシージャについては、まずプロパティ構文が変更されています。6.0ではプロパティのデータ型によって、SetまたはLetを使い分けていましたが、.NETではすべてSetとなります。
デフォルトプロパティはコードの中にDefaultキーワードを挿入することで設定ができ、値の設定が容易になっています。
継続的なAPIの利用
Windows APIには、対応する.NET Frameworkが提供するクラスライブラリが用意されています。
そのため、APIを使わなくとも実現できる操作が登場することはもちろん、6.0で使用していたAPIを、そのまま.NET環境に活用することも可能です。
アップグレードウィザードが、この変更についても自動で対応してくれます。
ただし、対応する.NET Framework クラスライブラリを利用するコードへの変更や、スレッド作成やWindowsサブクラス化を実行するためのAPIなどについては、手動での変更が必要なケースもあります。
エラー処理・例外処理の継続利用
Visual Basic固有のエラー処理・例外処理機能は、Visual Basic .NETにおいても継続的に利用が可能です。
見やすく、柔軟な例外処理が可能な機能性は汎用性が高く、より高度な処理を実現しています。ただし、同じプロシージャの中でエラー処理と例外処理の両方を実行することはできないため、注意しておきましょう。
また、エラー処理と例外処理のどちらを使うべきかという点については、.NETでは例外処理の優先的な利用が推奨されます。
その理由として、エラー処理を活用するリスクが挙げられます。ResumeやResume Nextといった魅力的な機能を活用する際、万が一エラー処理でエラーを解消できないと、エラーループが発生してしまうリスクが生まれるためです。
この場合、いつまで経ってもエラーの解消を行うことはできず、強制終了によって対処しなければならないため、できる限りこういった事態を引き起こさない方法が求められます。
そのため、例外処理の方が.NETでは好まれるというわけです。
レガシー機能の扱いについて
Visual Basic .NETでなくなる機能については、6.0の時点でできるだけ使わないようにすることも大切です。
On～GoTo／GoSub、GoSub／Returnや、LSetによるユーザー定義型変数の代入など、6.0にはあった機能が、.NETではなくなってしまうというケースがいくつか見られます。
これらはアップグレードウィザードが、自動的に対応してくれる場合もあります。しかし非常に冗長な処理へ変換される可能性や、そもそも対応しない可能性もあるため、これらは回避することが大切です。
あらかじめ上記のようなレガシー機能を使わずに6.0を利用することで、.NETへの移行をスムーズに行えます。
スムーズな移行のためのポイント：フォームとコントロール編
最後に、フォームとコントロールにおけるスムーズな移行のためのポイントをご紹介します。
フォームの変更
これまでVisual Basicが採用してきたフォームは、VB独自のフォームでした。しかしVisual Basic .NETでは、Frameworkが提供するWindowsフォームへと切り替わっており、よりなじみ深いシステムを利用できます。
フォーム作成はメニューから［Windowsフォームの追加］を選択し、簡単に行えるよう設計されています。自分で作成したフォームをテンプレートとし、新しいフォームを作成することも可能です。
また、フォームやコントロールを利用するためには、生成に必要な定義やプロパティを設定するためのコードを記述しなければいけません。
ただ、そのプロセスについても従来同様、フォームデザイナを利用してフォームやコントロールをデザインし、プロパティウィンドウでプロパティを設定するだけで完了です。
自動的に定義や設定がコードとして生成されるため、ノーコードで設定ができます。
アップグレードウィザードによって、これらの変更は自動的に行われるため、アップグレード後すぐに運用可能です。
フォームのプロパティ・メソッド・イベント
プロパティ、メソッド、イベントについては基本的に6.0のものをそのまま流用できますが、変更点もいくつか存在します。
まず、デフォルトボタンとキャンセルボタンの設定は、.NETにおいてはフォーム側で設定するものとして設計されています。
フォームのAcceptButtonプロパティに設定されたボタンがデフォルトボタンに、CancelButtonプロパティに設定されたボタンがキャンセルボタンへと変更されている点に注意しましょう。
そして、6.0においては自由に設定できた座標の単位（ScaleMode）ですが、.NETにおいてはPixelだけに一元化されています。
グラフィックメソッドについては、新しいGDI+（グラフィックスコマンドのセット）が提供されています。
6.0のようにCircleやCLSなどの豊富なメソッドは用意されていませんが、これまではWin32APIを利用しなければならなかった、高度なグラフィック機能が単一で実現することとなりました。
ダイアログボックスの変更点
6.0においてはShowメソッドを利用していたダイアログボックスですが、.NETでもShowメソッドは健在です。ただし、このShowメソッドには引数を指定できず、モーダルフォームを表示したい場合は、ShowDialogメソッドの利用が求められることとなりました。
ユーザーが選んだボタンの検出においても、コーディングが不要となっています。これまでは呼び出し側のフォームで検出するために、フォームレベル変数やグローバル変数などが必要でしたが、ノーコードでボタンとの関連付けが行われます。
標準コントロールの変更点
6.0で採用されていた標準コントロールは、.NET上では対応するWindowsコントロールによって、アップグレードされています。
例えば、フォームとの関連づけによって、コーディングなしでも簡単にショートカットメニューが作れるようになったことで、業務効率の改善が期待できます。
またTimerコントロールにおいては、6.0では「0」だったIntervalプロパティの最小値は.NETにおいて「1」となり、タイマーを無効にするためにIntervalプロパティを活用することはできなくなります。
その結果、あくまでもIntervalの設定のみに使う機能に特化し、混乱を防止してくれます。
変更点だけでなく、機能そのものが消滅するケースも存在します。ShapeコントロールやLineコントロールなど、グラフィック関連の機能についてはサポートが失われますが、Pictureコントロールのような代替手段が揃っているので、心配は無用です。
また、同名でインデックスにより識別されるコントロール配列も、.NETでは利用ができません。しかし、代わりになるコレクションや配列、また強化されたイベントの機能が追加されているので、やはり問題になるケースは少ないと言えるでしょう。
標準コントロールのプロパティの変更点
標準コントロールのプロパティの変更点について、大きな変化がTextプロパティです。
フォームやラベルコントロールに文字列を表示するためのCaptionプロパティは、全てTextプロパティに統合されることになったため、.NETではCaptionプロパティを活用するシーンはありません。
位置を指定、参照するLeftとTopプロパティの代わりには、Locationプロパティが活躍します。LocationプロパティはX（Left）とY（Top）をメンバとしてもつ構造体で、GDI+のメソッドにおいて利用されます。
LeftとTopプロパティについてもコーディングこそできますが、プロパティウィンドウには表示されないため、今後はX,Yに統合される可能性もあります。
その他の変更点
その他の変更点としては、まず特殊オブジェクトの削除が挙げられます。.NETではこれに代わる機能として、様々なオブジェクトが追加されます。
例えば、アプリケーションに関する情報は、.NET FrameworkクラスライブラリにあるAssemblyクラスが提供するようになります。
Debugオブジェクトについては、対応する機能が.NET Frameworkクラスライブラリにより提供されることとなります。
Screenオブジェクトが司っていたスクリーンに関する情報については、NET FrameworkクラスライブラリにあるScreenクラスが提供します。ただ、Visual Basic 6.0のScreenオブジェクトと共通するプロパティやメソッドは多くないため、この点には注意が必要です。
Clipboardオブジェクトをつかったクリップボードのやりとりについては、.NET FrameworkクラスライブラリにあるClipboardクラスが提供します。6.0のClipboardオブジェクトより多くの機能とボード形式を備えており、機能の強化が行われています。
変更や強化が行われる中、Errオブジェクトのように、引き続きの利用が可能なオブジェクトが存在する点もおさえておきましょう。
また、ドラッグ&ドロップについてはオブジェクトモデルが大きく変更されたり、DDEのサポートが終了したりなどの変更点も見られます。
ベトナムオフショアでのVBマイグレーションの実績
VB6.0継続リスクを解消、製造・在庫・販売管理システムを.NETへ変換、VBマイグレーション（migration）
なぜVB6の継続運用が問題なのか
現行の製造・在庫・販売管理システムについてVB6.0から.Netへの移行を行いWindows10での 動作を可能としました。VB6.0での継続には様々なリスクが伴います。マイグレーションすることで解消しました。
このほかにもVBマイグレーションの実績がございますのでお気軽にお問い合わせください。オフショア開発することで大幅なコストダウンが見込めます。
おわりに
Visual Basic6.0から.NETへの移行に伴う変更点は、このように列挙してみると様々なポイントが見られます。
現在の開発環境へどの程度影響を及ぼすのかについては、実際の現場と機能を照らし合わせて見なければわからないこともあります。
ただ、大抵の場合はアップグレードの際、自動的に.NETへ対応してくれるため、大きな問題を生むこともなく移行を進められるでしょう。
また、6.0と.NETの共存も可能なので、少しずつ最新環境へ移行する、ということも可能になっています。
まずは.NETのインストールを進め、最新環境の様子を実際に体感してみることが大切です。
