CoreCLRなBlackJumboDogにするとき仕組みを変更した理由と言訳 System.Windows.Forms

こんにちは。BlackJumboDogの置き換えに着手して1か月近くが経過しました。そこで、近況ばかりだったここに、当初大きく変更した点を記していきます。自分のまとめと疑問が含まれていますので少し脱線する要素は多くなります。また、答えを求めていた方にはそぐわないものになるかもしれないことを、あらかじめご了承ください。

本家BlackJumboDog

Bjdというプロジェクトがすべての基本となる機能を持っていました。それはExeでWindowsFormsのGUIを持っていました。GUIは起動すると最初に表示されサーバーの設定もログもWindowsサービスのセットアップもこれ一つできるというオールインワンの仕様です。お手軽さとして非常に大きく価値あるものだと思っています。勝手ながらこの記事では、これをBjd本体と表現することにします。

次に、サーバーの機能は参照する他のプロジェクトで実装されていました。ここに実装された設定は、自動的にGUIを追加する機能をBjd本体が提供していました。また必要に応じてダイアログを追加するような土台もBjd本体が提供していました。サーバーの通信処理(Socket)もBjd本体が多くを提供していました。実装は設定と通信プロトコルに集中したものです。勝手ながらこの記事では、Bjdサービスと表現することにします。

Bjdサービスのプロジェクトは、コンパイルによってDLL(アセンブリ)となりそれらを所定のディレクトリに配置しました。実行時には、その特定名称となるDLLを自動的に読み込んでいました。このときに使っていたのがリフレクション(System.Reflection名前空間にある機能)です。このリフレクションとは、型に厳密であるC# VB.NETなど.NetFrameworkの言語に対して、実行時における動的な処理を追加する機能です。コンパイル時にはないものを実行することができる反面、実行するまで結果はわかりません。

アセンブリは通常ファイル名またはアセンブリ名を指定して読み込まれていきます。GAC(GlobalAssemblyCache)はその一つです。これは署名されたアセンブリでインストールされたものだけが格納されている特別な領域です。.NetFrameworkを使ったことのあるかたはご存知のSystem、System.Data、System.Netなどのアセンブリはここに格納されています。これらに格納されたアセンブリを参照したアセンブリで実行イメージを作った場合。実行イメージである.exeと同じディレクトリにアセンブリファイルが存在する必要はありません。サードパーティ製のアセンブリもここにインストールされていることもあります。サードパーティ製のものを使って実装したものが、違う環境では動かなかった。そんな経験を持っている人はかなり多いんじゃないか?と思います。その場合は、このGACに同じものが入るようにインストールするか、コピーしたアセンブリ(DLL)をExeと同じディレクトリに配置する必要がありました。これは、VisualStudioのプロジェクトの参照設定でいう「ローカルコピー」というやつで実現できました。

さて、少し長々と書きましたが、上記の構成では、CoreCLRで動く.Net Coreではいくつか難問がありました。

System.Windows.Formsは存在しない

実は、、、.Net Coreには存在してません。便利だったこのGUI(実際これ肝だったと思う)は削除することにしました。ただし、こうすることで、構成の変更はどうやってやるのか?という話になってくるかと思います。これは、元のBjd本体で作ったoption.iniをそのまま使えることを前提として、この機能を削除しました。ログはファイルに出力されますので、直接の問題にはならないでしょう。CoreCLRはプラットフォームを選ばないものとして作られているため、将来的にもこれが提供される可能性は低いのではないかと思います。あくまで個人的見解ですが・・・。そのまま動かすというのであれば、Monoという.NetFrameworkのCross platformなものがあります。それを選べばいいわけです。こんなところで、CoreCLRを選ぶからこそのメリットを明確にしていく必要が出てきたわけでした。

(続く)