VB 6.0 から Visual Studio 2008 (VB .NET) への移行を考えています。

Question

はじめての投稿です。
右も左もわからないのですが、よろしくお願いします。

現在、VB 6.0 から Visual Studio 2008 (VB .NET) への移行を考えているのですが
簡単にソースコードやプロジェクトをコンバートすることができるのでしょうか？

また、コンバート後には、かなりのビルドエラーが出るものなのでしょうか？

もし経験者の方がおられましたら、ぜひ教えていただきたいです。

よろしくお願いします。

Answer 1

まとけん の発言:

はじめての投稿です。
右も左もわからないのですが、よろしくお願いします。

現在、VB 6.0 から Visual Studio 2008 (VB .NET) への移行を考えているのですが
簡単にソースコードやプロジェクトをコンバートすることができるのでしょうか？

また、コンバート後には、かなりのビルドエラーが出るものなのでしょうか？

もし経験者の方がおられましたら、ぜひ教えていただきたいです。

よろしくお願いします。

　一応、VB6.0からVisual Studio 2008への移行ですが、（Visual Studio 2008のエディションによりますが）、VB6.0のプロジェクトファイルを指定して開く事でアップグレードウィザードが起動します。
http://msdn.microsoft.com/ja-jp/library/dd297684.aspx

　ただしVB6でサポートされていたコントロールがVB.NETではサポートされなくなったりしていますので、かなりのビルドエラーが出るものと思ってください。
　また互換性のためにVB6のラッパークラスを使いますので、（特に座標系に関して）ソースコードが見にくくなります。

　移行後のソースは参考程度にとどめた方がいいかと思います。

MSDNでVB6からの移行ガイドも公開されていますので、参考にしてください。（ただし、内容がちょっと古いかも）
http://msdn.microsoft.com/ja-jp/library/dd314356.aspx

# 経験を基にした個人的な感想ですが、もし3層階層でプログラムが作成されているのであれば、
# 　・UI部は（アップグレーとされた部分を参考に）ほとんど作り直し。
# 　・ビジネスロジック部は、致命的な部分を修正。（この不分は、ある程度素直に移行してくれるとは思いますが）
# 　・データアクセス部は（ADOを使っていると仮定して）ADO.NETではなく、あえてADOを使うという選択肢もあると思います。

　あと、オブジェクト指向的な考えを持ったSE／PGが居るかどうかが問題になるかもしれません。（これが一番問題かも）
　アップグレードウィザードで移行したプログラムを修正して動くようにしたとしても、それは根本的な解決にはならないかと。

Answer 2

あくまでも個人的経験からです。プログラムの傾向によってかなり変わるのは確かでしょう。
自分の場合、VB6とVB2005とではかなり違う印象を持ちました。
最初、アップグレードでなく、簡単な（基本的な）練習ソフト作ってVB2005をある程度理解するよう努めました。
これだけなら、画面コントロール名称やプロパティ、メソッド表記がやや異なる程度で、違和感は少なかった。
有効だった参考書は、結局VB2005Helpでした。
ある程度VB2005アプリも作れるようになってから、VB6ソースのアップグレード実施しました。
（VB2005分からない状態でのアップグレードは、ほぼ無理と思います。）

最初、そのままVB6ソースをアップグレードしたら、エラーが莫大に出て、見る気にならなかった。
それで変換エラーが出ると分かっている箇所は、VB6ソースでコメント化してからやりました。
自分の場合、次のような箇所です。

 ・Dim配列：VB2005ではBaseは必ず0から：変更する
　0 は不使用でも良い。
・コントロール配列：VB2005に無い：個別の対策が必要
・File読み書きは全面変更要す
　Open、Close、Line Input、Print文など無くなったから、
　VB2005へアップグレード後、
　System.IO.FileかMy.Computer.FileSystemで全面的書き換え。
　しかし元からFileSystemでやってるなら、変更少ないかも。
・Graphic表示機能は全面変更要す
　（Line、Pset、Clsなどのメソッド無し、Form.Printも無し）
・WinAPI使っている箇所は全面変更要す。

するとエラーはかなり減りましたので、やる気が出てきました。
実際、グラフィック表示などしないアプリなら、ファイル読み書き箇所ぐらいかなと思いますが、
ADOやDataBase関係はアップグレード経験がありませんので、分かりかねます。
しかし、新規にADO.Netを利用する場合は、そう困難でもないと思います。

まず、VB2005またはVB2008に慣れるのが重要でしょう。
コントロールの名称やプロパティ、メソッド表記の違いをまとめたサイトもあるので、利用するのも。
（VB2003とVB2005はかなり違う印象ですが、VB2008はVB2005とほぼ同じの印象。）

オブジェクト指向については、自分はオールドプログラマーなのであまり必要性を感じていません。
それが無くてもアプリは作れる。が、NetFrameworkは無くてはならない存在になりました。
しかし複数名で開発する場合は、Class（モジュール）はメソッド公開の観点から必要でしょう。
その他に必要なケースはあるでしょうが、必要性薄いのに、オブジェクト指向にこだわるのには、
自分として、懐疑的です。

Answer 3

> CatTailさま

ご返信ありがとうございます。
互換性のためのVB6のラッパークラスを使用するということは
将来的には、このラッパークラスはなくなると思っておいた方が良いということになりますよね・・・。

しかも移行後のソースコードは参考程度で、UI部分をほとんど作り直すことになるのであれば
保守性を考えて、VB.NETやC#で一からリライトした方が良いのかもしれないですね。

オブジェクト指向についてはある程度は知識、実務経験があるので、なんとかなりそうです。
非常に参考になりました。ありがとうございました。

＞葉流奈津さま

ご返信ありがとうございます。
経験からのお話、とてもわかりやすく理解しやすいです。
C#の経験はある程度あるのですが、VB.NETはないので、下記は特に参考になりました。

・Dim配列が0から
  -> CやC#と同じになるのですね。知りませんでした。
・コントロール配列
  -> C#で作成できなかったのですが、VB.NETもそうなのですね。
・WinAPI使っている箇所
  -> .NET Frameworkが提供するもので置き換えということですね？

オブジェクト指向については同感、OOがすべてではないと思っています。
OOで書いたことにより、アプリが遅くなったり、コードが理解しづらくなるケースもあれば
OOで書いたことにより、非常にメンテしやすいコードになることもあります。
そこは見極めた上で作成していきたいと思っています。

非常に参考になりました。ありがとうございました。