2016/08/15(月)VB6のプログラムを修正してくれと言われたら
依頼はプログラムから送信しているメールの署名を変えてくれ、という簡単なものですが、メールの内容をプログラムで組み立てるのがメインのお仕事、というプログラムなので、署名もがっつりコードの中。
どうしたものかと調査した結果です。
結論からいうと、仕様が分かっているなら慣れたC#で一から書いた方が後々のため。
VB6の開発環境を入れようとしてみた
書き直すにしろ、プログラムの動作を確認するには開発環境があるのとないのでは大違い。MSDNで64Bit版を探したのですが、無い（当然か）。
Windows10に入れることはできるが、アンインストーラが対応していなので、削除は困難という情報もあり。
PCを汚したくないのでいったん諦める。
VB.Netにアップグレードしてみようとする
確か昔、Visual Studioが自動でアップグレードしてくれたはず、と思い調べたら、VS2008まで付いていたアップグレードウイザードがVS2010以降は消えたようで、必要ならVS2008を入れろ、と。ダウンロードのリンクが切れているので、MSDNからVS2008を落として入れたところ、入ることは入りましたが、変換ウイザードを走らせると、VB6関連のDLLが見つからない、VB6の開発環境を入れろ、というエラー。結局そこへ舞い戻るのか、と言う感じ。
VBUC（Visual Basic Upgrade Companion）を試してみた
MSDNサブスクリプションのライセンスあれば、１万行まで無料で変換してくれるというので登録してみました。ライセンスの問い合わせやっているのか、登録してもしばらくメールが来ませんでした。
30分以上待たされた気がします。
使ってみた結果は、最初スゲー！と思いました。
ほとんど修正無く（ちょっとエラーが出ましたが、直ぐ修正できるエラーでした）、見た目もそのまま動きました。
しかもデフォルトのまま変換したら、VS2015のC#になってるし（バージョンと言語は最初に選択できたもよう）。
ところが、いざ公開という段になってDLLが大量に追加されていることに気づきました。
元のプログラムは、exeと同じ場所にiniファイル（bcc先等設定）とデータの入ったcsvファイルを置いて実行する形になっていたのですが、同じフォルダにdllが10個以上追加されたら、紛らわしくてしかたありません。フォルダ丸ごとxcopyから配布方法を変えようとすると、やはりクリックワンス？ということで発行したら、exeやiniファイルの場所どこよ？csvはどこにおけば？ということになり、iniファイルはApp.Configへ、csvフォルダも参照してユーザー設定保存できるように変更。
いじり出すとメール送信はわざわざ外部のDLL使う必要ないよね、で書き直し。
SOAPのDLLもWeb参照に切り替え、で結構書き直しました。
他人の書いた、しかも慣れた言語ならまだしもVB6のコード（いきなりDim strHoge As String * 8みたいなのが並んでいて目が点になりました。なんでStringに数字を掛けるわけ？？とか）を読み一から書くよりは短時間かつ間違いなく書き換えられたとは思いますが、ソリューションに一つだけだったプロジェクトが12個になっているのはう～んちょっとと言う感じ。
出来るだけソースコードを書き換えなくても大丈夫なように、補間のライブラリを作成するというのは自動変換の考え方としては正しいのでしょうが、求めていたのとはちょっと違う気がしました。無理なものを求めている気がしますが…。
フォームだけは使いたい
フォームの作成は結構面倒。コントロールに名前をつけるのも時間がかかったりする。頑張って作っても、前の方が使い易かった、とか言われる。
できればこれだけでも流用したい、と思ったらVS2008の変換ウイザードが動く環境を作るか、いっそのことXAMLに変換する？