今日は、MagSite1 Version 0.14をリリースしましたが( https://mag.autumn.org/content.aspx?id=20031013163410 )、実はプログラム本体だけでなく、作業環境の整備も行っていました。
そのうちの1つが、リリースするアーカイブファイルを生成するバッチの作成です。こういうバッチは、繰り返しリリースするプログラムにはたいてい作るのですが、今回は少しだけ違った機能を入れることになりました。
まず、この手のバッチは何をどうするものか、ということから説明しておきましょう。プログラムを公開したり、誰かに渡したりする場合、必要なファイルをワンセットにして渡す必要があります。CD-Rに必要なファイルを全て焼いて渡す、という場合はそれで問題ないのですが、ネットワーク経由の場合は、個々のファイルがバラバラになってしまい、一緒に使ってはならないファイルが一緒に使われる危険があります。ですので、複数のファイルを1つにまとめて配布する意味があるわけです。
複数のファイルを1つにまとめるには、アーカイバーというソフトを使います。よく、アーカイバーは圧縮するソフトだという説明を見かけますが、これは間違いです。アーカイバーは複数のファイルを1つにまとめるソフトです。圧縮は圧縮ソフトが行うものです。
さて、うちではアーカイバーとしてUnlha32.dllを使っています。ZIP形式ならWindows XPで直接開けるので、そちらの方がベターと思いつつ、まだLHZ形式を使っています。Unlha32.dllを、NTTF(https://www.piedey.co.jp/softs/nttf.html )に入っているtlhaを経由して、バッチから呼び出してアーカイブさせます。
その際、単にアーカイブするだけでは不十分で、必要なファイルをすべて取り込み、不必要なファイルを全て取り除くようにバッチを作成しなければなりません。
それらの処理も含めると、とても複雑ではないものの、手動で間違いなく実行するのは面倒であるぐらいの複雑さになります。ですので、バッチの作成は、楽をするためには必須の手順と言うことになります。
さて、MagSite1でも、このようなバッチが必要という事情は同じです。しかし、これまでの他のプログラムと少し違った事情がありました。
何が違うのでしょうか。
それを理解するには、その前に、ReleaseビルドとDebugビルドの相違にまつわる問題を知る必要があります。プログラムをソースコードから実行ファイルにビルドする場合、ReleaseビルドとDebugビルドの2種類の形態を選べる場合が多くあります。Releaseビルドは本番実行用。Debugビルドは開発用です。たとえば、Debugビルドで、デバッグ用のメッセージを出力したり、読み込むディレクトリを別のディレクトリに切り替えていたりする場合があります。そういう状況で、Debugビルドを利用者に渡してしまうと、致命的な問題を引き起こす可能性があります。MagSite1は「扱うデータディレクトリが違う」という問題を引き起こします。つまり、間違ってDebugビルドを実行されてしまうと、せっかく作成されたコンテンツを扱うことができなくなってしまいます。
Visual Studio.NETで作成する通常プログラムのプロジェクトは、ReleaseビルドとDebugビルドの結果を格納するディレクトリが分かれています。Releaseビルドの結果をアーカイバーが取り込むようにバッチを書くのは容易です。バッチ実行前にReleaseモードでビルドを行えば、必要なファイルをアーカイブできます。もし、間違えてDebugビルドを行ってしまっても、古いReleaseビルドのファイルがアーカイブされてしまうだけです。これは致命的な問題ではありません。
しかし、Webアプリケーションの場合は、ReleaseとDebugでディレクトリが分かれていません。つまり、デバッグビルドを間違えてアーカイブしてしまう可能性を否定できません。
では、この問題をどう解決したのか。
バッチの中で、強制的にReleaseビルドを実行させる、という方法で解決しました。バッチの中でビルドさせる、というと、そんなことが可能なのかと思う人がいるかもしれませんが、これは可能です。
それには、Visual Stduio.NETのdevenv.exeに、/rebuildオプションを付けて起動します。ソリューションのファイルと、Releaseビルドであることをコマンドラインで指定すれば、統合開発環境が立ち上がる代わりに、コマンドラインないでReleaseビルドだけを行ってくれます。
これでバッチリ、バッチでバッチリ、間違いは起こりません。
この機能の存在は昔から知っていましたが、使うのは今回が初めてでした。しかし、とても簡単で使い勝手が良いので、これからはどんどん活用していくことになりそうです。(ああ、また楽をする手段を1つ覚えてしまった……)
ちなみに、この機能を使う上での最大の問題は、Visual Studio.NET 2002と2003混在環境で、どちらを使うか、きちんと制御することでした。いきなりdevenvリターンとするとVisual Studio.NET 2002のdevenv.exeが来てしまって焦りましたが、バッチの先頭で2003の環境変数設定バッチを呼んで回避しました。
