VB6からVB.NET2008への移行で苦労した所：
苦労した所：
・FlexGrid＞DataGirdViewへの移行
・ＡＤＯ＞ＡＤＯ．ＮＥＴ移行によるＤＢラップ化が結構めんどい。
・旧コードがそのままではかなり動かなくなっていた事
・ListBoxのitemプロパティが動かなくなっており、移行プログラムで
勝手に追加された余計なDLLを絡ませるのを避ける為に、全部打ち直した
VB6からVB.NET2008への移行に伴い、自分なりに
VB.NET2008を使うメリット、デメリットをまとめてみました。
メリット：
・自作の名前空間でスコープを好き勝手に多重化できる
・クラスの多重継承、フォーム自体の継承が出来る
これは非常に便利。不必要に関数を広域宣言しなくて済みます。
ただし、フォームの継承は、フォームエディタではサポートしていないようです。
また継承に関してはJavaと同じく、派生元が１つしか選べない。これは意外と落とし穴です。
インターフェイス定義を使えばそれほど問題はないんでしょうけど…。
・イベントに複数メソッドで追加でき、さらに動的にイベントを削除/追加できる
これは・・・旧VBでも出来たような気もしますが・・・やり方知りません。
・複数ファイルに渡って単一のフォームやクラスのコードを記述できる、
結果的に巨大ソースを記述する時、機能単位でファイルを分割できる
・コードを部分的に非表示にできる
※関数の途中区間だけ非表示に出来ないのが惜しい）、
・モジュールのインターフェイス一覧が見れる
・コード補完機能（インテリセンス？）が果てしなく便利
これだけの為にVB.NETを導入しても良いぐらいです。
これで、マウス操作の時間が大幅に減らせれば最高なんですけどね。
コードの構築速度が劇的に向上しています。が、インテリセンス系の
バグが多いため動かなくなる事が多々あるのが惜しい所
・VB.NETに限って言えばガベージコレクタ管理はかなり適当でも平気
(VC.NETだとオブジェクト解放を徹底的に行わないとアウト)
・マルチスレッド対応
旧VBではマルチスレッドにすると、年中強制終了していました。
・関数内にミニスコープを作り、その内部で一時変数を宣言できる
with Nothing〜End Withを使う事でローカルレベルの変数を減らす事が
出来るので、コードがとてもスッキリする
・CLRベースでコードを組むとVC.NETにソースを移行しやすい。
VB.NET本来の機能を無視してCLRで組むのが癖になって
しまいました。
などなど。
デメリット
・オフィスVBAにコードを流用しずらい。
・CLRに慣れるまでの壁が少し高い。覚えても結局 API 頼りになる
ケースがややある。
・旧コードからの移植は鬼門。
かなり悩みます・・・。が、次々と発売されるWindows、一から作り直す
手間を考えると、否応なしに移植に走らざるを得ませんよね・・・
最悪、以前の開発の半分ぐらいの工数はかかる・・・かな？？？
・MSDNヘルプが長い。冗長性が高い。MFCを勉強するぐらい意味不明な事がある
〜＞読み飛ばしずらい、チンプンカンプン
VBで敷いていた「分かりやすいコード体系」を放棄したから？
CLRをフル活用し過ぎたから？
意外と親切に書いてあるので、ヘルプを読みながら＋WEBで検索しながらなら
たいがいの機能は実装できるみたいです。
・CLR系DLL依存関係にかなり不安
どの程度まで互換性があるのかが不透明です…調べてませんし…
旧VBだと、使用するDLLを同じフォルダに押し込むだけで解決だったのですが。
・デバッグ時の動作が、旧VCのごとくの「固い」動作
イミディエイトでの簡易ウォッチ、ソース動作がしずらくなっています。
・フォーム編集中に、エディタが頻繁に元ソースを認識しなくなる。
フォームエディタが一度認識しなくなると、復旧にとっても時間がかかります…。
あまりに問題箇所の特定に時間がかかり、ぶっちゃげフォームエディタでの復旧は諦めたくなります…。
また、xxx.designer.vbを自力で手修正しないといけないケースが
よくあるので、ここもイタイ。
xxx.designer.vbを手修正するのはかなり頻繁にやる羽目になります。
ここはかなり悲惨！
その他：
従来家計簿では、FlexGridとaccessレコードセット、双方のソート機能
を使用して突合せ処理を行っていたのですが、
これが.NETでは駄目な感じになって死ぬほど苦労しました…。
結局、FlexGridを完全に切り離して DataGridView で完全に打ち直しました（汗）。
今後、ソフト開発を行う際は、MSが提供する複雑な動作をするコントロールは
極力使用せずにソフト設計をした方が良さそうです。
もっとも、５年も１０年もメンテするソフトを前提であれば、という話であり、
短期的な物であればかなり適当で良い筈ですが。
ただし、さすがに新しいコード体系をユーザーに要求した分、
新機能の使い勝手は素晴らしい出来になっています。
VB.NETの拡張機能はなかなか便利ではあります。
CLRランタイムも最初はとっつきにくいのですが、特に画像処理関連に
関しては便利な物が多い。ネイティブでAPIで作る手間を考えると
なかなか便利です。
ただし、マルチバイト文字処理系はかなりバグが多い印象で、ハングアップや
文字コード変換でつまづく事も多いかも知れません。
System.Text
System.Drawing
System.Windows.Form.以下
System.基本データ型
ここらは非常に便利でした。ここからまず覚えましょう。
ですが・・・果たしてあと何年使用できるんでしょうか？
また文字コードがVB6と.NETでは異なるため、ここら辺も問題ありの箇所です。
なにより、旧VB体系のコードがそのまま動かない、ここが痛い。
旧VB6ではListBoxの１つのデータに対して、１つのObject型データ？を
保存できたのですが、これがVB.NETだと追加のDLLが必要になってしまっています。
MFCはあくまでWin32 API のラッパーDLLという位置付けであり、
「元となるAPIはどんな物を使うのか？」を理解していないと
訳の分からない動作をするインターフェイスばかりでした。
CLRもどうもその系譜を受け継いでいる印象です。
「BASIC」の名を冠するほどは、初心者に優しく無い気がします…
代入時にオブジェクトへのポインタを渡すのか、オブジェクトのコピーを
渡すのか、ここらを理解してないと駄目過ぎですね。
VB.6はWin32の成り立ちを知らないでも、かなり適当にコード出来るのですが。
.NET系は、多少、１〜３日ぐらいはWin32ネイティブのウィンドウソフトを組んでから
やり始めた方が良いかも知れませんね。
でも、一度でもVB.NETで開発を始めたら最後、
「もう旧VBなんて使ってられない」
こうなる事間違いなしです。
なにしろコードの自由度が高いので・・・。
最後に、フリーでVB.NET2005/2008 Express Editionを
無償公開して頂いたマイクロソフト様に
感謝の意を表します。
ありがとうございました！
願わくば、本ソフトがVisualStudioへの
開発フィードバックになれば幸いです。
戻る
ほーむ