VBのマイグレーションについて

VB6からVB2005へのマイグレーションについて質問です。
マイグレーション後の問題について。

恐らく、マイグレーション後
ソースに若干変化があると思います。
go to文をtry catch文に修正したりする必要があるのかな・・
と予想したりしています。

これ以外にもソース上の変化・問題について教えてください。

No.3 ベストアンサー 回答者： khazad-lefty 回答日時： 2008/10/27 21:37

VB2005以降はかなりVB6に近い構文が通るようになっています。

実際
＞go to文をtry catch文に修正したりする必要
はなく、そのままでも動きます。
VB2003までは対応していなかったVB用の関数もかなりの部分対応しているし、何より「モジュール」なんてのができてますしね。

ということで、ソースそのものよりも、「参照設定」で設定しているようなコントロール・部品関連が問題です。
言語自体は同じ文法で動いても、そこで使われている部品は当然そのままで動くとは限らないわけで。
というか、標準コントロール以外ならまず動かないでしょうし。
そのあたりはNo2でいろいろ書かれているのでそれを参照すればいいかと。

アップグレードユーザーのために、いろいろ機能が加えられているのですが、それでも業務アプリとして（特にパフォーマンス・ソースの可読性）ちゃんと動くかは別物ですから…機械的なコンバート＋αと考えてるとひどい目にあうかもしれないです。

No.2 回答者： equinox2 回答日時： 2008/10/26 15:12

>ソースに若干変化があると思います。

簡単なソースであれば若干で済むかもしれませんが、ちゃんとした業務に
使用されていたまともなソースであれば、仕様書とソースを参考にして
新たに制作したほうが良いくらい違います。
＃VB6ではできてVB.NET以降ではできない機能もあります。

また、サードパーティのOCXなどを使われている場合には、.NET対応版が
存在するかをまず調べてください。

MicrosoftのOCXが使われている場合には、列挙して各々が.NETで対応されているか
調査してください。

DBアクセスがある場合には、何を使用しているか調べてください。
RDO、ADO、DBベンダーのOCXなど

.NETの標準はADO.NETです。使われているDBではサポートしていますか。
＃オラクル、DB2ならネイティブプロバイダが準備されています

onerrorの処理とTry Catchでは設計思想が違います。

いずれにせよ、業務用のソースであれば一筋縄では行きません。

No.1 回答者： edp3142 回答日時： 2008/10/26 12:15

まず技術調査として実際にやってみる・パターンを抽出する事だと思います。

業務であればなおさらです。

それをせずに机上で予測を立てても、作業工程・規模は測れないと思うのですが。

他の人のケースを聞いても、あなたの対象ソースで100%そうであるかは、ソース毎に実装が異なりますので、参考にならない可能性がありますよ。