プログラミングの話題です。
Xamarinとか考えるとVisual StudioではVB.NETはオワコンでC#に移行すべきなんだろうなぁという雰囲気は以前からありましたが、Visual Studio for Mac(C#のみ)なんてのまで出てきちゃってさらに加速してきた感があります。Swiftもオープンソース化されて今後様々なプラットフォームの開発ができるようになるかもですが、現状C#ならWin/Mac/iOS/Androidいけちゃうわけですし。もちろんそれぞれGUI周りの実装が違うので、1つのソース(プロジェクト)で各プラットフォームのビルドが一発でできちゃう、とかいう世界にはまだならないですが、関数とかオブジェクトとか(内部処理的な)ライブラリを共有、転用できるだけでも大きなメリットでしょう(想像)。
ということでVisual Studio 2017を入れて見たついでに、実験的にフォーム1つだけの小さな自分用WindowsアプリをC#で作り直してみようかと思い立ちました。C#の勉強の為にはゼロから作り直す方が良いんでしょうが、とりあえず世の中にはVB->C#のコード変換をしてくれるツールがたくさんあるということだったのでまずはそちらで雰囲気をつかんでみることに。ポインタアレルギーを脱してないヘタレプログラマなので、Cと名のつくものは不安が先行しがち(^^;)。
で、最初に試したローカルアプリ型のツールはいまいちよくわからなかったので、ブラウザ上でコードをサクっと変換してくれるこちらを使ってみました。プロジェクトレベルで変換してくれるわけでなく、あくまでテキストレベルでVBコードをC#コード文法に書き直してくれるだけなので、VS2007上でC#の新規Windowsフォームアプリケーションのプロジェクトを作りました。そしてフォームデザイナーで土台となるフォーム(Form1)のプロパティだけ揃えておいて、載ってる部品を全選択して一括コピペします。ペーストされる座標が揃いませんが、カーソルキーで適当に揃えて確定。これでボタンやリストなどは名前やプロパティをそのまんま移植できました。次にForm1のコードをエディタで開き、上記サイトでまるっと変換したC#コードをペースト、、、しただけでは上手くいきませんでした。以下思い出せる範囲でメモ。
■using周り
冒頭にインポートするライブラリが、デフォルトのテンプレートと、変換したもので食い違います。特に変換した方のコードには、
1 |
using Microsoft.VisualBasic; |
なんてのが含まれています。どうもVB特有の関数やオブジェクトを使用するDLLらしいです。個々にうまく変換できなかったものを手直ししてても意外とVBにしかないものがあるみたいです。C#で全面的に書き直すのも手なんですが、.NET Frameworkに含まれるDLLなので使ったからといってユーザに別途追加インストールが必要になるとかではないので、特にこだわりがなければ使ってもいいんじゃないでしょうか。ゼロから書き直すプロジェクトなら避けた方がスリムなんでしょうけど。
特にファイルコピー周りの処理でVBの方が便利なところがあって、最終的には
1 |
using Microsoft.VisualBasic.FileIO; |
というのも追加していくつかVB固有機能を使用しました。
逆に変換コードにはあってデフォルトテンプレートにあるものは名前からして使わなそうなものはコメントアウトしました。
■各メソッドの貼り付け場所
C#のバージョンの違いなのか、Form1クラス定義の開き方も少し違ってたりなので、念のためテンプレのままとし、クラス内のメソッド定義単位でペーストしました。
1 2 3 4 5 |
public Form1() { } |
なんかはテンプレの方にもあるので重複に注意です。
■コードの手直し
ぶりっとコードをペーストすると盛大にエラーが出ます。さすがにそのまま完璧に変換とはいきません。
例えば、配列の添字がVBでは()、C#では[]ですが、これは自動では置換してくれません。()が他の意味にも使われている箇所があるので、自動では判別が難しいようです。
例えば、
1 |
Button1.Text = tmp(0); |
なんてコードに対して、「メソッド名が必要です」が出て意味不明ですが、tmp[0]に直してやると消えます。文法的にはtmpという変数にいきなり引数がついてるので、「temp.hoge(0)みたいにメソッドがあるはずじゃねぇの?」という推論なんでしょうかね。まぁVSの推論エンジンですら、そこは配列の添字じゃないの?と提案できないくらいなので、サードパーティの無料自動変換プログラムができなくても責められないでしょう。わかってしまえば単純作業なのでせこせこと直していきます。
次に多かったのは、
1 |
string[] words = sentence.Split(" "); |
のように文字列を文字列で分割して配列に格納したりするコードに対して、「‘string’ から ‘char’ へ変換することはできません。」と出ます。(古い.NETの)C#のSplitは分割文字として文字列ではなく単一の文字(char型)しか使えなかったらしい名残のようです。もともと分割の区切り文字が1文字の場合は、char型であることを明示するよう、ダブルクオートをシングルクオートに直してやるだけでOKです。
1 |
string[] words = sentence.Split(' '); |
とか。では2文字以上の文字列を使いたい時は?ちょっと文法が変わりますが、同じ.Splitで
1 |
string[] words = sentence.Split(new[] { ". " },StringSplitOptions.None); |
のようにすればいいみたい。めんどくさ!
■My.settingsへのアクセス
VB.NETではアプリの設定など短い情報を保存するMy.settingsという仕組みがあります。もちろんC#にもあるんですが、アクセス方法がちょっと違います。
1 |
<span style="color: #ff0000;">My</span>.Settings.WindowHeight |
となってる箇所に「現在のコンテキストに ‘My’ という名前は存在しません。」と出ます。MyのかわりにProperties(複数形なので注意)とし、Settingsの後にDefault.を挿入します。
1 |
<span style="color: #ff0000;">Properties</span>.Settings.<span style="color: #ff6600;">Default.</span>WindowHeight; |
これは変換サイトの方で頑張ってほしかった案件です。
もちろんセッテイング項目は自分で作り直しています。どこかのXMLファイルをコピーすれば一発かも知れませんが、まぁ数個だったので手で移しました。
■中身が移ってないイベントハンドラがある
変換後のコードで、変換処理にこけたのかわかりませんが、イベントハンドラの{}の中身が空のままのコードがいくつかありました。エラーもないのでちょっと恐いですね。全体見渡したり、数をチェックしたりして抜けがないか確認が必要です。
■GUIパーツと各イベントハンドラコードの紐付け
ある程度コードを手直し、よやくエラーが0になってビルドしてフォームが表示された時は感激です。しかし、一瞬後に絶望へとかわります。どのUIパーツをクリックしても反応しないのです。試しにデザイナーから適当なボタンをダブルクリックして、コードエディターに挿入されたイベントハンドラにMessageBox.Showとか書くと機能します。つまり、コピペでもってきた各ハンドラとデザイナー上のUIパーツが紐付いていないようなのです。一瞬、全てのパーツに同じ事をして{}内を書き写さないとダメなのかと青ざめましたが、幸い少しだけマシな方法がありました。
デザイナーでどれかのパーツを選択し、プロパティウインドウでイナズマのアイコンをクリックします。そうするとここにそのUIパーツが受け取れるイベント一覧が出てくるので、Clickなどコードを割り付けたいイベントを探し、その右列をクリックします。するとプルダウンメニューで当該Formのコード内にあるハンドラ一覧が出るので、選択してやれば紐付け完了です。
UIパーツはたくさんありますし、ひとつのUIパーツにClickとDouble ClickとEnterとなどなど複数のイベントを設定することも少なくないので、結構大変な作業になります。VBとC#のプロジェクトを同時に開いて1つずつ見比べながら書き写してくしかありません。またコード側からどこにも紐付いてないイベントハンドラが残ってるかどうかを知る術もありません。
まぁきっとこれもデザイナーのソースとなるテキストファイルを丸コピーできれば一緒に反映されるような気もするんですが、わかりませんでした。
■まとめ
上に書いた以外ではファイル周りで変換しきれていないコードがあったりしましたが、まぁVB.NETとC#の違いを調べながら書き直すのは良い勉強になりました。
むしろ大変なのは先のイベントハンドラの紐付けや設定項目の再作成など、Visual StudioのGUIでする作業の移植ですね。バージョン情報などを含むアセンブリ情報などもごっそりやり直しです。これは今回使ったようなコード変換系のサービスの難点でしょう。
先に使ったプロジェクトを読み込んで変換するタイプだとここらも一括で面倒みてくれるかも知れません。Webツールに移行する前にもう少しいじり倒してみればよかったかな。今回はForm1しかない小さなツールだったのでまだよかったですが、より大規模なソフトウェアの場合などは抜け漏れのチェックも大変になってきます。
いずれにせよC#自体は想像してたほどVBとかけ離れてたり、いきなりポインタの理解を迫られたりするようなものではなかった気がします。少なくともVBでできていたことを移植するだけなら、いくつかのVB固有関数を除けばほぼ単純な文法置換(()を[]とか文末セミコロンとか)で済みそうです。残りのVBプロジェクトを全部C#に移行させる理由はいまんとこないですが、今後新規に作る時はC#にしてみようかなというくらいの気持ちにはなりました。あとは買っておいた解説本を眺めておこうと思います。