VB研公開ゼミ議事録第2回 私はコレで、VB 6を卒業しましたデジタルアドバンテージ 遠藤 孝信2006/12/09 |
|
好評をいただいた前回のVB研公開ゼミに引き続き、2回目のVB研公開ゼミが去る2006年11月10日に開催された。
第2回 VB研公開ゼミ 「私はコレで、VB 6を卒業しました」
今回のテーマは、Visual Basic 6.0(以下、VB 6)から.NETへの移行はいかにして行えばよいかである。
Windows VistaでもVB 6の業務アプリケーションは動作するとはいうものの、いつまでもVB 6のシステムを使い続けてはいられない、VB 6だけで開発をしてはいられないということは、もはやここで説明するまでもないだろう。
しかし、すでにある多くのVB 6のアプリケーション資産はどうなるのか。どうすれば効率的に移行できるのか。移行に際して何をどのように学べばよいのか。そもそも移行することが最善の解決策なのだろうか。
また、クラス・ライブラリやオブジェクト指向など、.NETでの開発はVB 6に比べて明らかに複雑で難しそうである。そのためなかなか.NETの世界に踏み込めないVB 6開発者も少なくないと聞く。実際、何がハードルとなるのか。みんなどうやってそれを乗り越えてきたのか。
NECラーニングの山崎氏によるプレゼンテーションに続いて行われたパネル・ディスカッションでは、そういった疑問や不安を解消すべく、VB 6とVB.NET*の双方に詳しい以下の方々に集まっていただき、議論していただいた。
パネリスト |
NECラーニング株式会社 IT・NW研修本部 マネージャ 山崎 明子 氏 マイクロソフト株式会社 デベロッパー&プラットフォーム統括本部 デベロッパービジネス本部 デベロッパー製品部 シニアプロダクトマネージャ 鈴木 祐巳 氏 開発者代表 尾崎 義尚 氏 グレープシティ株式会社 ツール事業部 テクニカルエバンジェリスト 八巻 雄哉 氏 |
モデレータ | 株式会社デジタルアドバンテージ 代表取締役社長 @IT Windows Server Insiderフォーラム編集長 小川 誉久 |
パネル・ディスカッションの様子 |
* .NETで使用可能なVisual Basicには、Visual Studio .NETとVisual Studio .NET 2003に対応したVisual Basic .NET、Visual Studio 2005に対応したVisual Basic 2005が存在するが、本稿では.NET版のVBという意味で、すべて「VB.NET」と表記している。 |
本稿では、約90分にわたって行われたパネル・ディスカッションの内容を要約してお伝えする。(以下、敬称略)
アップグレード・ウィザードはやはり使えない?!
【小川】 まずは現在あるVB 6の資産を、どのようにすればスムーズに移行できるのかというところから始めたいと思います。ただ、すでに移行作業を経験された方のお話を聞くと、「VB 6から.NETの移行はあきらめた方がよい」という意見もあるようです。
トレーナーが本業である山崎さんは、すでに多くのVB 6開発者に対して.NETへの移行についてトレーニングされていると思いますが、どのような意見をお持ちですか?
NECラーニング株式会社
山崎 明子 氏 |
【山崎】 移行についてよくいわれるのは「アップグレード・ウィザード*って使えませんよね」ということです。実際、アップグレード・ウィザードで生かせる部分は限られていますが、もちろん生かせることのできる部分は生かすべきです。しかし、.NETではライブラリやコントロールが大きく変わっているため、ユーザー・インターフェイスやデータ・アクセスの部分は断然新規に作った方がよいと思います。
【鈴木】 私の立場的には不適切な発言かもしれませんが、確かにアップグレード・ウィザードは期待の割にできないことがけっこう多いと思います。あまり過度な期待はしていただかない方がよいと思います。
* アップグレード・ウィザードは、VB 6のプロジェクトを.NETに変換するツール。Visual Studio .NETやVisual Studio 2005に含まれる。IDEからVB 6のプロジェクトを開くと起動し、ウィザード形式で変換を行える。 |
【小川】 尾崎さんはVB 6ベースの業務アプリケーションを.NETに移行したご経験があると伺っていますが、具体的にどうされたのですか?
【尾崎】 そのときはVB 6で作られたアプリケーションを、アップグレード・ウィザードを使ってVisual Basic .NET 2003に移行しました。まずエラーが何百も出て、それを1つ1つつぶしていかなくてはなりませんでした。それを行った後はどうにか動いたんですが、実行時にExcelが解放されないなどといった問題が生じ、その後のサポートがまた非常に大変でした。
【小川】 Excelが解放されないとは?
開発者代表
尾崎 義尚 氏 |
【尾崎】 アプリケーション内でExcelを帳票ツールとして使っていたのですが、そのプロセスが解放されていなかったのです。VB 6なら(Excelオブジェクトを参照している変数に)Nothingをセットすればそれで解放されていたのですが、.NETはそれでは解放されません。この違いを開発者が理解していなかったので、そのまま移行してしまい実行環境で問題が起きてしまいました。
これはほんの一例ですが、このような経験から、VB 6のコードはそのまま簡単に移行はできないというのが私の印象です。コンパイル・エラーが出なかったからといってアップグレードできたとは絶対に思わない方がいいでしょう。
結局、移行したとしても、テストには新規開発と同等か、それ以上の工数がかかることになります。結果的には、最初から.NETで作り直した方が早いという場合が少なくないと思います。
アップグレード・ウィザードで移行するその前に
【小川】 それは、元のVB 6アプリケーションの作りに問題があったということでしょうか?
【尾崎】 そうですね。マイクロソフトが「VB 6ではこのように作ってください」という推奨どおりに作っていれば、アップグレード・ウィザードですんなり移行できます。しかし実際には、開発者は(そういう推奨の作成方法に従わず)自由に作ってしまうものです。
【山崎】 (VB 6のプロジェクトで)実行時バインド(遅延バインド)を使用していたのではないですか? 移行時に一番厄介なことの1つがこの実行時バインドです。
例えば「As 型名」ときちんと書かずに「As Object」とか、型を指定しないで変数を宣言した場合、その変数を用いて.NETで変更されたプロパティやメソッドにアクセスしているコードが100カ所あったら、100カ所全部で手作業による変換が必要になります(以下のコード例を参照)。もし、最初のところで正しく型を宣言していれば、残りの100カ所は全部アップグレード・ウィザードが適切にコンバートしてくれます。
|
||||
アップグレード・ウィザードがうまく変換できない例 | ||||
正確に型を指定せずに変数oを使用しているため、変換後のコードでは、実行時にCaptionプロパティが見つからずエラーとなる。 |
|
||||
アップグレード・ウィザードにより正しく変換される例 | ||||
変換前に変数oがCommandButton型であると明記しておくと、.NETのButton型に変換され、CaptionプロパティもTextプロパティに変換される。 |
実はこういったことを発見して、アドバイスしてくれるツールもマイクロソフトから提供されています。「Code Advisor for Visual Basic 6.0」という無償のツールです。
Code Advisor for Visual Basic 6.0 − 日本語版
もちろんこのようなツールを使わなくても、最初から推奨の作成方法どおりに書いていればよいのですが、VB 6では遅延バインドを利用したコードが書けてしまうし、それを禁止できません。たとえ自分1人がきちんと書いていても、ほかのすべての開発者が同じように推奨の方法を守ってくれるわけではないので、結局は……というケースはありますね。
【小川】 ある程度そういうルーズな記述ができてしまっていた、ある意味それが便利で扱いやすかったという部分もあったと思いますが、そういうことが.NETへの移行であぶり出されてしまうということですね。
【八巻】 そういうときには、変換したものを手直しするよりも、まずVB 6で書いたものをいったん正しく書き直して、その後でコンバートを行った方がよいかもしれません。
【山崎】 それは正しいアプローチだと思います。VB 6からアップグレード・ウィザードを使ってコードを移行するのであれば、まずCode Advisorを使ってVB 6のコードを解析し、最適なコードにしてからアップグレード・ウィザードを使用すべきです。先ほどお話ししたように、変数の宣言部分をきちんと書いておけば、アップグレード・ウィザードによる変換の精度はかなり向上します。
【八巻】 そうですね。アップグレード・ウィザードを使って移行するなら、事前にVB 6のプログラムをきれいに直すところから始めるのが作業効率の面でもよいと思いますし、同時に勉強にもなると思います。アップグレード・ウィザードを実際に利用するかどうかは別として、それを使って変換してみることで、VB 6のコードが.NETでどう変わるかを見るだけでも勉強になると思います。
【尾崎】 勉強用として利用するにはいいと思いますが、個人的な経験からいわせてもらえば、やはり既存のアプリケーションを.NETに移行しようと思うのはあきらめて、新規で作った方がいいと思いますよ(笑)。
移行せずに新規作成すべきか?
【小川】 そうですね。忙しすぎて勉強なんてしている場合ではないという方も多いと思います。VB 6と.NETでは基盤となる開発フレームワークが根本的に違っており、それを表面上だけで何とかしようとすると、それ自体に手間がかかるし、実際に移行後もサポートなどで苦労することも多いというのは、まさに現場的な意見だと思います。結局、お勧めは新規で作った方がよいということになりますか?
【八巻】 確かにそうですね。移行は難しいかもしれませんが、実は.NETで一から書くことはそんなに難しくないと思います。だから、ぜひ一から書くことにチャレンジしてもらいたいです。すると「あっ、なんだ。VB 6と同じように書いたけど、けっこう動くもんだ」と思っていただけると思います。まずは試してみることが重要だと思います。
【鈴木】 別の面から考えると、移行せずに作り直すことのメリットとしては、アプリケーションをより使いやすく作り直すことができるという点が挙げられると思います。当然ながら、使いにくいアプリケーションは移行しても使いにくいままです。
もう一点、作っている側としては、誰が作ったか分からないアプリケーションを直すよりも、自分で書いた方が楽しいということもありますね。移行後の1000行のコードを500行直すよりは、1000行のコードを書く方が、作る側としてはモチベーションを高く保てると思います。
【小川】 なるほど分かりました。いまVB 6のプログラムを.NETに移行しようとお考えの方は、まずは新規で作り直すことを検討してみた方がよさそうですね。
INDEX | ||
VB研公開ゼミ議事録 | ||
第2回 私はコレで、VB 6を卒業しました | ||
1.アップグレード・ウィザードはやはり使えない?! 移行せずに新規作成すべきか? | ||
2.オブジェクト指向プログラミング/膨大な.NETのクラス・ライブラリ | ||
3.コンビニ的に便利なMy機能/アプリケーション・モデルの違い | ||
「VB研公開ゼミ議事録」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|
- - PR -