6.0資産の2005移行について への返答
投稿で使用できる特殊コードの説明。(別タブで開きます。)
以下の返答は逆順(新しい順)に並んでいます。
投稿者 リスナー (学生)
投稿日時
2008/11/27 04:55:01
どうもこんばんは。
お二人レスありがとうございます。
業界に関する書籍を読んでいるとコボル資産の話が出てきて、
するとVBにも言えると思い質問してみた次第です。
明快なご回答どうもでした。
バイト先などでワードやエクセルの画面を見ることはあるのですが、
偶然にも何らかのシステム画面を見るという経験がなく、
システムというと大手企業やその子会社、
それもある程度の規模のある中小企業、
そういったところが発注するものといったイメージがあったのです。
妙な選別だとは自分でも思いますが、
たとえば近くの道を歩いていて通りがけに、
あるオフィスの中の様子が見えたとして、
何らかのシステムを導入しているというイメージがわかず、
また、導入するとしたらどんなシステムが可能性としてあり得るのだろう、などと考えていました。
私は将来的にはVBでのシステム開発を目指しているので、
少し営業的な部分を気にしているのだと思います。
やっぱり社内にＩＴ部署のある企業だと外注はわざわざしないのかなあとか。
VBで実用的なシステムを開発して売り込む場合どんな会社なら導入に積極的なのか、など。
そういった意味でお二人のレスは具体的だったので助かりました。
それでは。また。
お二人レスありがとうございます。
業界に関する書籍を読んでいるとコボル資産の話が出てきて、
するとVBにも言えると思い質問してみた次第です。
明快なご回答どうもでした。
バイト先などでワードやエクセルの画面を見ることはあるのですが、
偶然にも何らかのシステム画面を見るという経験がなく、
システムというと大手企業やその子会社、
それもある程度の規模のある中小企業、
そういったところが発注するものといったイメージがあったのです。
妙な選別だとは自分でも思いますが、
たとえば近くの道を歩いていて通りがけに、
あるオフィスの中の様子が見えたとして、
何らかのシステムを導入しているというイメージがわかず、
また、導入するとしたらどんなシステムが可能性としてあり得るのだろう、などと考えていました。
私は将来的にはVBでのシステム開発を目指しているので、
少し営業的な部分を気にしているのだと思います。
やっぱり社内にＩＴ部署のある企業だと外注はわざわざしないのかなあとか。
VBで実用的なシステムを開発して売り込む場合どんな会社なら導入に積極的なのか、など。
そういった意味でお二人のレスは具体的だったので助かりました。
それでは。また。
投稿者 魔界の仮面弁士 (社会人)
投稿日時
2008/11/26 22:26:41
> それには2005の知識のみならず6.0についても知っていないとできないのでしょうか？
両方を知っている人の方が遥かに効率が良いです。
たとえば、フランス語の映画があって、それを日本語に翻訳する事を想像してみてください。
日本語は達者でもフランス語は片言程度という人に、完全な翻訳は望めないですよね。
それに言語のみならず、それぞれに特有の文化についても知っておいた方が良いですよね。
コンピュータ言語でも同様です。翻訳結果に曖昧さが含まれていてはならないのですから、
両方の言語に通じているべきと言えます。また、6.0 では API が必須だったが、2005 では
プロパティ設定だけで OK …などといった場面もあるでしょうから、両方の仕様の違いを
熟知している人の方が、移行作業に有利である事は想像に難くありません。
一応、6.0 と 2005 は文法的には似通っているため、前提知識があまり無くとも、
ある程度までは読み解けると思います。問題は、コントロールの機能の違いなど、
環境に依存する部分や、「VB6 に固有の部分」の把握の度合いにあるでしょう。
・まずは、MSDN の『Visual Basic 6.0 ユーザー向けのヘルプ』を参照のこと。
・Visual Basic マイグレーション センターも必読です。
http://msdn.microsoft.com/ja-jp/vbasic/cc707251.aspx
・VB6 登場から 10 年以上経っているので、当時利用していたコンポーネントが、
現在は入手できない(もしくはサポートされない)可能性を考慮しておくこと。
・移行目的には、Microsoft.VisualBasic.Compatibility.DLL を参照設定して
Microsoft.VisualBasic.Compatibility.VB6 名前空間のクラスを使うことが有効。
(ただし最終的には、この名前空間のクラスを使わないコードに置き換える事が望ましい)
・データベース操作は大きく異なる。6.0 の ADO と 2005 の ADO.NET は別物である。
(2005 で ADO を使うことも不可能では無いが、問題点が多いので避けるべき)
・6.0 には、「コントロール配列」という特殊なコレクションが存在する。
・文字コード変換を伴うコードと描画系メソッドの扱いが大きく異なる。
・6.0 では、オブジェクトの代入には『Set』という特殊なキーワードを使う。プロパティにも
Get/Set/Let の 3 種があるので要注意。(2005 のプロパティは Get/Set のみ)
・Excel 操作など、いわゆるオートメーション(OLE オートメーション)の移行は鬼門。
移行は不可能では無いが、この分野に関しては 6.0 を引き続き利用した方が問題が少ない。
・Declare を使う場合、2005 の [IntPtr] は 6.0 の Long に相当する。
・Declare を使う場合、2005 の [Integer/Int32/UInteger/UInt32] は 6.0 の Long に相当。
・Declare を使う場合、6.0 の Long を 2005 で何に翻訳するべきかは文脈依存。(通常は IntPtr または Integer)。Any 型も悩みどころ。(このあたりは VB のみならず、API の知識も要求される)
> そもそも移行というのは外観も内部設計もまったく新しく2005以降のVBで作り直す意味なのですか？
そういう場合もありますし、そうでない場合もあります。
処理内容によっては、アップグレード ウィザードにかけるだけで済む場合も(ごく稀に)ありますし、
画面制御が複雑なアプリなどでは、リメイクした方が早い場合もあるでしょう。
> こういう案件だとあまり納期まで日数をくれないなんていう噂話を耳にしたもので。
そこは現場と担当者次第なので、何が一般的という事も無いのですが、短絡的に考えれば
別言語(java、MFC等)から移行する場合よりは、納期は短縮される事が多いです。
# 逆に「VB6 でできたんだから .NET でも可能なハズ」の一点張りで、仕様変更がままならないような
# 現場では、互換性がかえって足枷になってしまった例もあるにはありましたが…それは例外として。
ただし、6.0版の仕様がはっきりしていない場合、調査工数を上乗せすべきと思います。
仕様書等がしっかりしている場合は、開発工数は大きく減らせるかも知れませんが、
行うべきテストの総工数については、そう変わらないと思います。
なお、過去の移行作業を鑑みると、日数が必要な場合とそうでない場合とがありました。
2.0→4.0(16bit) では、コンポーネントの互換性面から、それなりの手間が必要でした。
2.0→4.0(32bit) では、移行にかなりの手間がかかりました。
4.0(32bit)→5.0 では、移行の手間はやや少なかったです。
5.0→6.0 では、移行を気にする必要はほとんどありませんでした。
6.0→2002(7.0)は、初めての.NETという事もあり、移行は大変でした。
2002(7.0)→2003(7.1)は、移行の手間はほとんどありません。
2003(7.1)→2005(8.0)は、移行の手間はやや少なかったです。
問題は、バージョンを飛び越える場合ですが、6.0→2002 と 6.0→2005 を比較すると、
差はほとんどない(もしくは、2002への移行よりも若干容易)といった所でしょう。私見ですけれども。
> 6.0資産が世の中に多いのかどうかも想像がつきません。
多い現場も皆無な現場もあります。が、少なくとも私の回りには幾らか生き残っています。
また、Vista でも VB6 ランタイムがサポートされた事実を考えれば
(2002はサポートされなかったのに)、それなりのニーズがあったとみるべきでしょう。
> 移行といった場合、仕様の策定からまったくやり直すのか、
> それとも今あるシステムを見ながら単にコピー的に.NETのルールで書きなおすだけなのか、
そのどちらもありえます。経験則なので難しいところではありますが、
移行作業が膨大になれば、リプレースが有効と判断される場合もあるでしょう。
いずれにせよ、新システムを作る場合、前の機能に＋αが求められるのが常ですから、
仕様の見直しは必須となるケースが多いです。単純な置き換え部分については、当方では
・要求仕様…＋α分が無いなら、ほとんど変化なし。
・ＤＢ仕様…あまり影響しない可能性が高い。
・コード設計仕様…全面的に見直しが必要。
・入出力仕様…文字コードの扱いが異なる点に関して若干の工数が必要。
・テスト仕様…画面系は見直しが必要。
・結合テスト仕様…システム間通信がある場合は設計から要確認。
といったところでした(他社、他業態ではどうだか分かりません)。
# ＰＪ計画仕様、パッケージ適合仕様等々、いわゆる「仕様書」は
# 数多くあるので、あまり細かく述べる事はできませんけれども。
> そしてそれには6.0と2005の両方の知識が欠かせないのか、そのあたりを教えてください。
開発規模にも寄りますが、両方の知識を有する人が、最低1人は居た方が良いでしょう。
ただしチームの力量が高い場合において、片方だけの知識で成功した例を見た事はあるので、
絶対に欠かせないのかと問われると、そうとも言い切れない面もありますけれども。
> たとえば役場とか公共機関でVBによるシステムとかって使われていたりするものですか？
ありますよ。少なくとも自分は、VB4 の頃から何度かその手の開発に関わっていますし。
またかなり昔ですが、市販のCD ライティングソフトに使われていた例も見た事があります。
DLL は別言語で作られ、画面周りが VB 製でした(現行バージョンでは違うようですが)。
その他(これも最近の事では無いのですが)、富士通系の PC で、プリインストールされているゲームが
すべて VB 製のものであった物を見た覚えがあります。後はフィットネスクラブで、予約システムの
端末を除いたら、フォームのアイコンが VB アプリの物であったものとか…。
両方を知っている人の方が遥かに効率が良いです。
たとえば、フランス語の映画があって、それを日本語に翻訳する事を想像してみてください。
日本語は達者でもフランス語は片言程度という人に、完全な翻訳は望めないですよね。
それに言語のみならず、それぞれに特有の文化についても知っておいた方が良いですよね。
コンピュータ言語でも同様です。翻訳結果に曖昧さが含まれていてはならないのですから、
両方の言語に通じているべきと言えます。また、6.0 では API が必須だったが、2005 では
プロパティ設定だけで OK …などといった場面もあるでしょうから、両方の仕様の違いを
熟知している人の方が、移行作業に有利である事は想像に難くありません。
一応、6.0 と 2005 は文法的には似通っているため、前提知識があまり無くとも、
ある程度までは読み解けると思います。問題は、コントロールの機能の違いなど、
環境に依存する部分や、「VB6 に固有の部分」の把握の度合いにあるでしょう。
・まずは、MSDN の『Visual Basic 6.0 ユーザー向けのヘルプ』を参照のこと。
・Visual Basic マイグレーション センターも必読です。
http://msdn.microsoft.com/ja-jp/vbasic/cc707251.aspx
・VB6 登場から 10 年以上経っているので、当時利用していたコンポーネントが、
現在は入手できない(もしくはサポートされない)可能性を考慮しておくこと。
・移行目的には、Microsoft.VisualBasic.Compatibility.DLL を参照設定して
Microsoft.VisualBasic.Compatibility.VB6 名前空間のクラスを使うことが有効。
(ただし最終的には、この名前空間のクラスを使わないコードに置き換える事が望ましい)
・データベース操作は大きく異なる。6.0 の ADO と 2005 の ADO.NET は別物である。
(2005 で ADO を使うことも不可能では無いが、問題点が多いので避けるべき)
・6.0 には、「コントロール配列」という特殊なコレクションが存在する。
・文字コード変換を伴うコードと描画系メソッドの扱いが大きく異なる。
・6.0 では、オブジェクトの代入には『Set』という特殊なキーワードを使う。プロパティにも
Get/Set/Let の 3 種があるので要注意。(2005 のプロパティは Get/Set のみ)
・Excel 操作など、いわゆるオートメーション(OLE オートメーション)の移行は鬼門。
移行は不可能では無いが、この分野に関しては 6.0 を引き続き利用した方が問題が少ない。
・Declare を使う場合、2005 の [IntPtr] は 6.0 の Long に相当する。
・Declare を使う場合、2005 の [Integer/Int32/UInteger/UInt32] は 6.0 の Long に相当。
・Declare を使う場合、6.0 の Long を 2005 で何に翻訳するべきかは文脈依存。(通常は IntPtr または Integer)。Any 型も悩みどころ。(このあたりは VB のみならず、API の知識も要求される)
> そもそも移行というのは外観も内部設計もまったく新しく2005以降のVBで作り直す意味なのですか？
そういう場合もありますし、そうでない場合もあります。
処理内容によっては、アップグレード ウィザードにかけるだけで済む場合も(ごく稀に)ありますし、
画面制御が複雑なアプリなどでは、リメイクした方が早い場合もあるでしょう。
> こういう案件だとあまり納期まで日数をくれないなんていう噂話を耳にしたもので。
そこは現場と担当者次第なので、何が一般的という事も無いのですが、短絡的に考えれば
別言語(java、MFC等)から移行する場合よりは、納期は短縮される事が多いです。
# 逆に「VB6 でできたんだから .NET でも可能なハズ」の一点張りで、仕様変更がままならないような
# 現場では、互換性がかえって足枷になってしまった例もあるにはありましたが…それは例外として。
ただし、6.0版の仕様がはっきりしていない場合、調査工数を上乗せすべきと思います。
仕様書等がしっかりしている場合は、開発工数は大きく減らせるかも知れませんが、
行うべきテストの総工数については、そう変わらないと思います。
なお、過去の移行作業を鑑みると、日数が必要な場合とそうでない場合とがありました。
2.0→4.0(16bit) では、コンポーネントの互換性面から、それなりの手間が必要でした。
2.0→4.0(32bit) では、移行にかなりの手間がかかりました。
4.0(32bit)→5.0 では、移行の手間はやや少なかったです。
5.0→6.0 では、移行を気にする必要はほとんどありませんでした。
6.0→2002(7.0)は、初めての.NETという事もあり、移行は大変でした。
2002(7.0)→2003(7.1)は、移行の手間はほとんどありません。
2003(7.1)→2005(8.0)は、移行の手間はやや少なかったです。
問題は、バージョンを飛び越える場合ですが、6.0→2002 と 6.0→2005 を比較すると、
差はほとんどない(もしくは、2002への移行よりも若干容易)といった所でしょう。私見ですけれども。
> 6.0資産が世の中に多いのかどうかも想像がつきません。
多い現場も皆無な現場もあります。が、少なくとも私の回りには幾らか生き残っています。
また、Vista でも VB6 ランタイムがサポートされた事実を考えれば
(2002はサポートされなかったのに)、それなりのニーズがあったとみるべきでしょう。
> 移行といった場合、仕様の策定からまったくやり直すのか、
> それとも今あるシステムを見ながら単にコピー的に.NETのルールで書きなおすだけなのか、
そのどちらもありえます。経験則なので難しいところではありますが、
移行作業が膨大になれば、リプレースが有効と判断される場合もあるでしょう。
いずれにせよ、新システムを作る場合、前の機能に＋αが求められるのが常ですから、
仕様の見直しは必須となるケースが多いです。単純な置き換え部分については、当方では
・要求仕様…＋α分が無いなら、ほとんど変化なし。
・ＤＢ仕様…あまり影響しない可能性が高い。
・コード設計仕様…全面的に見直しが必要。
・入出力仕様…文字コードの扱いが異なる点に関して若干の工数が必要。
・テスト仕様…画面系は見直しが必要。
・結合テスト仕様…システム間通信がある場合は設計から要確認。
といったところでした(他社、他業態ではどうだか分かりません)。
# ＰＪ計画仕様、パッケージ適合仕様等々、いわゆる「仕様書」は
# 数多くあるので、あまり細かく述べる事はできませんけれども。
> そしてそれには6.0と2005の両方の知識が欠かせないのか、そのあたりを教えてください。
開発規模にも寄りますが、両方の知識を有する人が、最低1人は居た方が良いでしょう。
ただしチームの力量が高い場合において、片方だけの知識で成功した例を見た事はあるので、
絶対に欠かせないのかと問われると、そうとも言い切れない面もありますけれども。
> たとえば役場とか公共機関でVBによるシステムとかって使われていたりするものですか？
ありますよ。少なくとも自分は、VB4 の頃から何度かその手の開発に関わっていますし。
またかなり昔ですが、市販のCD ライティングソフトに使われていた例も見た事があります。
DLL は別言語で作られ、画面周りが VB 製でした(現行バージョンでは違うようですが)。
その他(これも最近の事では無いのですが)、富士通系の PC で、プリインストールされているゲームが
すべて VB 製のものであった物を見た覚えがあります。後はフィットネスクラブで、予約システムの
端末を除いたら、フォームのアイコンが VB アプリの物であったものとか…。
投稿者 よねＫＥＮ (社会人)
投稿日時
2008/11/26 19:56:47
> 6.0で作成したシステムを.NETに移行するという話をけっこう身近で聞くのですが、
> それには2005の知識のみならず6.0についても知っていないとできないのでしょうか？
VB6.0からVB2005への移行に関わらず、移行を行うにはその移行元の知識と移行先の知識の両方が必要です。
ただ、現実には両方を十分に知っている人ばかりを集められるとは限らないので、
移行元を知っている人、移行先を知っている人、移行元も移行先も知っている人などを適材適所に配置して
協力しながら作業をします。
> そもそも移行というのは外観も内部設計もまったく新しく2005以降のVBで作り直す意味なのですか？
移行元の言語から移行先の言語に極力機械的に移行しようとする場合と
そのシステムが本来満たすべき要件や仕様を把握した上で、移行先の言語で新規に作りなおすという場合もあります。
しかし、どちらの場合でも、移行元の言語のソースコードを分析する必要があることは多いので、
移行元の言語の知識はやはり必要になります。また、機械的に移行を進める場合でも、
やはり本来満たすべき要件や仕様の把握(そのシステムの設計書などの各種資料を参照したり、
お客様に確認したり)といった作業は発生します。
仕様を把握するアプローチとソースコードを分析するアプローチはどちらか一方だけ使う
というより、両方を最大限に使って行うものと考えていただければよいかと思います。
> 6.0資産が世の中に多いのかどうかも想像がつきません。
どのくらいの数かは把握してませんし、把握している人もいないと思いますが、
実感としては多いと思いますよ。
> それには2005の知識のみならず6.0についても知っていないとできないのでしょうか？
VB6.0からVB2005への移行に関わらず、移行を行うにはその移行元の知識と移行先の知識の両方が必要です。
ただ、現実には両方を十分に知っている人ばかりを集められるとは限らないので、
移行元を知っている人、移行先を知っている人、移行元も移行先も知っている人などを適材適所に配置して
協力しながら作業をします。
> そもそも移行というのは外観も内部設計もまったく新しく2005以降のVBで作り直す意味なのですか？
移行元の言語から移行先の言語に極力機械的に移行しようとする場合と
そのシステムが本来満たすべき要件や仕様を把握した上で、移行先の言語で新規に作りなおすという場合もあります。
しかし、どちらの場合でも、移行元の言語のソースコードを分析する必要があることは多いので、
移行元の言語の知識はやはり必要になります。また、機械的に移行を進める場合でも、
やはり本来満たすべき要件や仕様の把握(そのシステムの設計書などの各種資料を参照したり、
お客様に確認したり)といった作業は発生します。
仕様を把握するアプローチとソースコードを分析するアプローチはどちらか一方だけ使う
というより、両方を最大限に使って行うものと考えていただければよいかと思います。
> 6.0資産が世の中に多いのかどうかも想像がつきません。
どのくらいの数かは把握してませんし、把握している人もいないと思いますが、
実感としては多いと思いますよ。
投稿者 (削除されました) ()
投稿日時
2008/11/26 19:55:42
(削除されました)
投稿者 リスナー (学生)
投稿日時
2008/11/26 07:27:37
どうも皆さんこんばんは。
6.0で作成したシステムを.NETに移行するという話をけっこう身近で聞くのですが、
それには2005の知識のみならず6.0についても知っていないとできないのでしょうか？
そもそも移行というのは外観も内部設計もまったく新しく2005以降のVBで作り直す意味なのですか？
仕様の変更というより単に6.0から2005に書き換えるという意味合いで、
こういう案件だとあまり納期まで日数をくれないなんていう噂話を耳にしたもので。
私は6.0に触れた経験はありませんし、6.0資産が世の中に多いのかどうかも想像がつきません。
しかし多いなら、
また、それを同じVBで今後も続けるクライアントがあるのだとしたら、
そういった案件を想定することは重要かなと思い質問しました。
似たような話なのかどうかコボル資産の移行の話なども別車線で出ていますし、
移行といった場合、仕様の策定からまったくやり直すのか、
それとも今あるシステムを見ながら単にコピー的に.NETのルールで書きなおすだけなのか、
そしてそれには6.0と2005の両方の知識が欠かせないのか、そのあたりを教えてください。
VBの現場という意味合いでなかなかイメージしにくいところがありまして。
たとえば役場とか公共機関でVBによるシステムとかって使われていたりするものですか？
あまり言語は関係ないのかもしれませんが、例えば業種とかケース・スタディとかでもいいので、
VBの開発現場の情報をください。
6.0で作成したシステムを.NETに移行するという話をけっこう身近で聞くのですが、
それには2005の知識のみならず6.0についても知っていないとできないのでしょうか？
そもそも移行というのは外観も内部設計もまったく新しく2005以降のVBで作り直す意味なのですか？
仕様の変更というより単に6.0から2005に書き換えるという意味合いで、
こういう案件だとあまり納期まで日数をくれないなんていう噂話を耳にしたもので。
私は6.0に触れた経験はありませんし、6.0資産が世の中に多いのかどうかも想像がつきません。
しかし多いなら、
また、それを同じVBで今後も続けるクライアントがあるのだとしたら、
そういった案件を想定することは重要かなと思い質問しました。
似たような話なのかどうかコボル資産の移行の話なども別車線で出ていますし、
移行といった場合、仕様の策定からまったくやり直すのか、
それとも今あるシステムを見ながら単にコピー的に.NETのルールで書きなおすだけなのか、
そしてそれには6.0と2005の両方の知識が欠かせないのか、そのあたりを教えてください。
VBの現場という意味合いでなかなかイメージしにくいところがありまして。
たとえば役場とか公共機関でVBによるシステムとかって使われていたりするものですか？
あまり言語は関係ないのかもしれませんが、例えば業種とかケース・スタディとかでもいいので、
VBの開発現場の情報をください。
たまたま、記事を発見しましたので。
マイクロソフトヘルプ
ときには、Visual Basic 6.0 のコード例を Visual Basic 2008 で使用したい場合もあります。Visual Basic 6 コードのアップグレード ツールを使用すると、Visual Basic 6.0 のコードを変換して Visual Basic 2008 のコードに挿入できます。コードの中に変換できなかった部分がある場合には、コメントが追加され、コードを動作させるために必要な対処を説明するヘルプ トピックへのリンクが示されます。詳細については、「方法 : [Visual Basic 6 コードのアップグレード] ダイアログ ボックスを使って Visual Basic 6.0 のコードをアップグレードする」を参照してください。