先週は風邪っぽくてぼちぼち休んでたら日記上げるタイミングを外した。日記なのに週一なのは置いといてだな。
本をたくさん取り込んでたりしたがまだまだあってつらい。
文字描画時のアンチエイリアスはいろいろ考えたが、ステンシル使ってるとMSAAするしか簡単な方法が思い付かないので諦めた。簡単じゃない方法なら思い付くけど、上手くいくかわからん上に重そうだと思うとそこまで頑張って試す価値が見えん。またそのうち考えよう。
3回目くらいのインストーラ作り。1度目はInstallShield Express LEだかなんだかで作って、2度目はVisualStudio拡張として提供されてる簡単インストーラプロジェクトで作って、今度はWiXで。
InstallShieldはライセンスがよくわからんのといちいち登録しないと落とせないのでめんどくさくてやめた。Azureの仮想マシンに入れて自動ビルドしていいのかよくわからんのがね。あと登録すると宣伝メール送りまくってきやがるし。
簡単インストーラプロジェクトは機能としては足りそうな感じだったけど、プロジェクトファイルフォーマットが謎の形式だった。バージョン番号上げる時に自動で書き換えたいので、謎のフォーマットはちょっときつい。いじるの躊躇われる形の謎フォーマットだったし。
だったらいっそWiXでちゃんと作るべきかとWiXの勉強を始めた。GUIでなんとか簡単に作れないものかと思ってたけど一度作っちゃえばあとはテキストで管理できた方が楽だしね。
でまあチュートリアルとかドキュメント見て作ってみたんだけど、めんどくせーなこれは！ いやまあWindows Installer自体がめんどい物だからこうなってんだろうけど。
コンポーネントをどう捉えていいのかわからんのが難しい。インストールの単位で、ファイル一つずつ作ればいいの？とか思うんだが、それをやろうとするとめちゃくちゃ記述量が増えてしんどい。コンポーネント全部にId設定しなきゃいけない理由はあるんだろうか。 逆に複数のファイルを1つのコンポーネントに入れようとすると、GUID自動生成するには1つのファイルがバージョン付きのKeyPathでそれ以外はバージョン無しのファイルじゃないといけないとエラーを出される。じゃあGUIDをいちいち指定しなきゃいけないのかとも思ったけど、GUIDってファイルの変更があった場合新しくしなきゃいけないのかな？だったら手動でやるのは難しいな。あとComponentにはDirectoryが入らないので、複数階層にわたってファイルを入れるにはComponentを分けなきゃいけない。うーん、概念がわからん。 チュートリアルを見ると多量のコンポーネントがあっても問題ないから怖がらずにコンポーネントを作りまくれ！的なことが書かれているが、パフォーマンスが怖いとかじゃなくて記述量的にメンテ不能になりそうなんですよ……。
記述量が大変なことになる問題は解決方法があって、heatっつープロジェクトファイルからファイルを列挙してWiXのwxsファイルを自動生成してくれるツールがある。これを使えば沢山のファイリがあっても自動生成されるから安心だ！ と、言いたいところだが、これがあれば全部解決ってわけでもなくて、生成したうえでいじりたいところとかあるのが困る。exeにショートカット作りたいなーとか思うと、exeファイルのコンポーネントに入れるのが楽そう。しかしそのためには自動生成したあとのファイルいじる必要があって困るなぁと。 あとチュートリアルには、インストーラは片手間に作るもんじゃねぇなんだよ自動生成なんかに頼るな手で書けおらぁ！的なことが書かれてるけどちょっとハードすぎませんか。
今のところは、exeファイルのプロジェクトだけは手動でいじって、依存するアセンブリは自動生成で十分なのでその方向でいくことにした。 書いてて思ったけど、これ手で書くにしてもwxs吐き出す独自フォーマットを作って生成しちゃった方がいいのかもしれないな。全部手で書くのは逆にメンテナンス性悪くなりそうだわ。まあそのうち必要になったらやろう。
インストーラが必要になる理由として.NET4.5必須にしたというのがあるので、.NETのインストールもついでにやってほしいところ。簡単にできるんだろうと調べてみるが、どうもmsiに組み込むことはできない模様だ。Bundleを作ってそこで.NETのインストーラを呼び出すべしとのこと。えーめんどいー。 めんどいけどそれしか方法がないなら仕方ないか。ていうか簡易インストーラプロジェクトでも.NETのインストールしようとするとSetup.exeが別に生成されてたし。
Bundleを作るの自体はドキュメントに沿って書けば簡単だった。exeファイルにmsiも埋め込んで単一のファイルにできるし簡易インストーラプロジェクトのそれよりいいね！ ただUIが独自の物になってしまって、msi標準のUI使えないのが痛いなぁ。msi標準のUIを表示させることもできるけど、BundleのBootstrapperApplicationの独自UIが出てインストールを開始してからさらにmsiのUIが出る形になってしまう。最初からmsiのUIだけ出てくれればいいんだけど、.NET Frameworkのインストーラも実行するからその分も表示しないとだし無理か。 あと独自UIでインストール先の指定ができるんだけど、その初期値の設定とmsiへの受け渡し方法がドキュメントに書いてなくて悩んでしまった。ソースとか見てわかったけどちゃんと書いておいてほしいなぁ。 他にはUIに日本語が無かったり、日本語にしてみたらボタンに文字が収まらないので大きくしてみたりと見た目をいじってインストーラとしては出来た。高解像度環境だとUIがぼけるのは非常に気になるが、そこをいじるのは大変なんで妥協することにした。 起動するプログラムファイルを指定しておくと、インストール完了時にそいつを起動できるようになるのは便利だね。
インストーラが出来たので試してたが、インストール後の初回起動時にWindowsファイアウォールの警告が出てくるの気になるな。これインストール時に例外登録しておいて、アンインストール時に登録削除すべきでなかろうか。 大変そうだけどよくありそうなパターンだしどうせ例はあるだろうと調べてみると、例どころかWiXの拡張ライブラリとして標準で用意されてた。ショートカットと同じように指定しておくとそれだけで例外登録と削除をしてくれた。すごい簡単！便利！
というわけでインストーラ本体はだいたい出来たっぽい。さて本体の方もいじらないといけないのだが……。
PeerCastStationには新しいバージョンが来たら通知してくれる機能がついてる。今だと新しいバージョンを見つけたら変更点を表示しつつ、ブラウザでzipをダウンロードできるようにしてるだけだ。
インストーラが出来たのでアップデートもインストーラに対応したい。インストーラ版を使ってる場合にはインストーラ版の新しいバージョンを、従来通りのzip版1を使ってる場合はzip版の新しいのを落とせるようにするべきだろう。
となると現在はアップデート検出用のRSSにzipへのリンクしか書いてないが、インストーラへのリンクも書いてどっちがどっちか判別できる必要がある。さらに、今自分がどっちのバージョンで動いてるか知ってなきゃいけないってことだ！めんどい！ 自分がどっちのバージョンで動いてるかはconfigファイルにでもつっこめばいいんだけど、それってインストーラビルドする前にconfigファイル書き換えないといけないってことですよね。めんどいわー。 ただめんどくさいめんどくさい言ってても仕方ない。難しいならともかく、単にめんどくさい場合の解決方法は考えるのをやめてめんどくさいことを愚直にやることだけだ。というわけで実装した。
アップデータのUIではインストーラかzipを選択できるが、既定は今使ってる方のバージョンとした。なるべくインストーラ版に気付いてほしいからね。 ただ動作が気になるところがあって、今はリンクをブラウザで開くだけだが、インストーラ版だったら落として実行までやるべきではなかろうか。zip版でも勝手に展開してファイル置き換える……のはさすがに大変だからやらないにしても、ブラウザに頼らず落とせてもいいんじゃない？ しかしアップデータでダウンロードもできるとダウンロード進行状況のUIも欲しくなるしあわわ……。 UIは作るの大変なんだよねぇ。
まあしばらくはあんまり凝ったことせずに様子見て、アップデートがめんどくさければもっと便利にするか。え、既にめんどくさいのは分かってるって？そうだなぁ……。
インストーラを忌み嫌う抵抗勢力のためにzip版は存在し続けるのだ！まあそうでなくともmonoで使うにはインストーラでは困るわけで、どっちにしろインストーラ一本化はできない。 ↩