@jsakamoto

IIS6 に ASP.NET MVC 配置のためにワイルドカードマッピング追加するには JScript だけではできなかった

2010/10/28追記

その後、IIS6 に ASP.NET MVC 配置のためにワイルドカードマッピング追加するには JScript だけでできることが判明。
詳しくはこちらに投稿。

開発した ASP.NET Web アプリケーションを IIS6 に配置する話。
最近の IIS7.x だとまた事情が違うのだが、まだまだ IIS6 も根強く居残っているので。

さて、IIS6 上に ASP.NET Web アプリを配置するにあたっては、仮想フォルダのマッピングや、アプリケーションの作成などなど、IIS に対する構成作業が発生する。
インターネットインフォメーションサービスマネージャを使って毎度手作業で構成してもいいが、度々同じ構成作業が発生するようなら、スクリプトにまとめておくのが吉。
他のメンバーが作業するときにも役立つ。


ということで、IIS6 に対する構成作業の自動化なのだが、自分は WSH ( Windows Script Host ) ベースで、.wsf ( Windows Script File ) や .hta ( HTML Application ) の形で 、ADSI を JScript から呼び出す実装でスクリプト化している。

昨今は PowerShell などもあるし、古くは VBScript が IT 管理業務でよく使われているようなのだが、自分の場合、Web アプリケーション開発で JavaScript にはなじみが深いため、構文などで迷うことの無い JScript を選んで使っている。

さてさて、こうして作成・再利用してきた .wsf/.hta なのだが、最近はクラシカルな ASP.NET Web Form アプリではなく、ASP.NET MVC アプリの開発・配置も着々と増えてきた。

ここで、IIS6 上で ASP.NET MVC アプリを稼働させる場合、拡張子とISAPIハンドラとの関連づけが問題になる。

ひとつの解は、ASP.NET MVC のルーティング規則にて、何かしら拡張子 ― よくあるのは .mvc ― を付けることに決め、この拡張子と ASP.NET ISAPI 拡張とを関連づけする方法。

もうひとつは、IIS6 の「ワイルドカードアプリケーションマッピング」に、ASP.NET ISAPI 拡張を結びつけることだ。
「ワイルドカードアプリケーションマッピング」に登録された ISAPI 拡張は、要求の拡張子に関係なく呼び出されるようになる。
ASP.NET MVC における /SomeController/SomeAction といった URL をハンドルするにはうってつけだ。

ということで、ASP.NET MVC アプリ配置用のスクリプトにおいて、ワイルドカードアプリケーションマッピングも同時に設定することにした。

さて、IIS6 の拡張子とISAPI 拡張との関連づけは、JScript では次のように ScriptMaps プロパティで参照できる。

var vdir = GetObject("IIS://localhost/W3SVC/1/Root/SomeAppDir");
var scriptMaps = vdir.ScriptMasp;

この ScriptMaps プロパティが返すオブジェクトの型は何か?
どうやら VBArray のようだ。
.hta の場合、次にようにすると、すでにこの仮想フォルダにマッピング済みの、ひとつめのマッピング情報が表示される。

ａｌｅｒｔ(scriptMaps.getItem(0));

ワイルドカードアプリケーションマッピングを追加するには、拡張子を指定するところで、"*" を指定したマッピングを追加するだけでよい。

インターネットインフォメーションサービスマネージャのプロパティ画面だと、ワイルドカードアプリケーションマッピングの設定は別枠になっているので、ADSI 上もなにか特別なプロパティやメソッドでアクセスするのかと思ったが、そんなことはなく、他の拡張子関連づけと同じく ScriptMaps プロパティで参照・設定するのであった。

（ちなみに、Windows XP 上の IIS 5.x でも、インターネットインフォメーションサービスマネージャ画面にはワイルドカードアプリケーションマッピングの設定枠はないが、拡張子に "*" を指定した関連づけを追加してやることで、ワイルドカードアプリケーションマッピングができあがり、ASP.NET MVC アプリをホストできる）

では、scriptMaps にワイルドカードアプリケーションマッピングの要素をひとつ追加...と思ったのだが、なんと、これができない。

JScript 上、VBArray は読み取り専用
なのだそうだ。

は?

ということは、
JScript だけでは、どうがんばってみたところで、ワイルドカードアプリケーションマッピング（というか、任意のマッピング）は追加できない
ということである。

IT 管理系のスクリプトに VBScript がよく使われているっぽい（少なくともネット検索の結果では VBScript の事例を多く見かける）理由は、もしかしてこういうところにあるのか、などと今頃思ったり。


とにかく。

既存の JScript ベースのスクリプトを全面的に VBScript に書き換えるのもアホらしいので、マッピングの追加部分だけを VBScript で書くことにした。
幸い、.wsf や .hta であれば、ミクスドランゲージは可能である。

.hta であれば、script タグの lang 属性で仕分けるだけである。
ということで、こんな感じ。

<script lang="VBScript">
　Function AddMap(maps, newEntry)
　　ReDim Preserve maps(UBound(maps) + 1)
　　maps(UBound(maps)) = newEntry
　　AddMap = maps
　End Function
</script>

<script lang="JScript">
　var vdir = GetObject("IIS://localhost/W3SVC/1/Root/SomeAppDir");
　var scriptMaps = vdir.ScriptMasp;
　scriptMaps = AddMap(scriptMaps,"*,c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll,3");
　vdir.ScriptMaps = scriptMaps;
　vdir.SetInfo(); // 変更内容を保存
</script>

ちなみに上記は .NET4 ではなく .NET3.5ベースの ASP.NET MVC を配置する場合の例。

同じホスト ( .wsf や .hta ) の中であれば、VBScript で定義した関数やプロシージャを JScript から呼び出すことは普通に可能である（VBScript から JScript で定義した関数を呼び出すのも然り）。
COM 万歳、である。

VBScript は不慣れなのだが、ReDim ステートメントで Preserve オプションを指定しながら新たな要素数を指定することで、配列中の既存の要素はそのままに配列の要素数を増減できるとのこと。
また、UBound 関数で、配列の要素数を取得できるらしい（正確には、VBScript では配列の添え字の下限を0以外に変えられるので UBound は厳密には "上限" ということなのだが）。

こうして、VBScript をちょっと混ぜつつ、大体を JScript の記述としたまま、ワイルドカードアプリケーションマッピングの追加をスクリプトでできるようになった。

LINQ とラムダ式でコマンドライン引数のオプションスイッチを解析する

とある、C++ & MFC で書かれた Windows GUI アプリを、C# + WPF に移植中。

移植とは言ったが、要求仕様だけは同じに、いちから書き直している。

それでも、CArrayList に対する for ループと if 文で最小値を探索する箇所を、LINQ to Object の Min 拡張メソッド一発で書けたり、非常に小気味よい。

Visual Studio のインテリセンスも、VS.NET時代の C++ から遙かに進化した VS2010 の C# 上なので、開発生産性は当時の比ではない。

さらに当時はまだうまく書けなかった単体テストを書きながら開発できているので、開発のスピードもさることながら（ビルドして、起動して、GUIに手作業で何か入力して...などとまどろっこしいことをしなくて良い。テストコードさえ書けば、あとは Ctrl + R, T で開発したコードが確認される）、今後の改良改善についてもデグレートの心配をしなくて済む（100%発生しないとは言わないが）。

などと快進撃を続けていたのだが、はたと困った要件にぶちあたった。

このアプリ、コマンドライン引数でオプションスイッチを受け付けるのである。
オプションスイッチ有無の判定や、オプションスイッチに続く引数の取得をどのように実装したらよいだろう?

たとえば次のようなコマンドライン引数が与えられたときに、

MyWPFApp.exe /foo test.txt /bar

bar スイッチの有無の判定や、foo スイッチの有無の判定と、foo スイッチに添えられた引数（上記例だと "test.txt" ）の取得を行わなければならない。

その当時は、コマンドライン引数のオプションスイッチを解析する、専用のパーサーライブラリを利用しており、割とコンパクトに判定処理を記述できていた。
イメージとしては次のような感じ。

CmdLineParser::GetOptinValue(_T("foo")) --> CString(_T("test.txt")) が返る

しかし今は C# 上に移植中であり、このようなライブラリの手持ちはない。

また、このようなオプションスイッチ解析ごときで、あまりぐずぐず実装に時間をかけたくない。

インターネットで検索する?
CodePlex で何かライブラリが公開されているか調べてみる?
いやいや、その調べる時間もまどろっこしいし、よしんばいいライブラリが見つかったとして、そのライブラリの学習時間も必要だ。

ということで、よし、スクラッチでその場しのぎのコードで済ませてみよう、と考えた。
なにせ、今は LINQ があるのだ。

まずは、大元のコマンドライン引数の取得から。

これは System.Environment クラスの GetCommandLineArgs メソッドで、コマンドライン引数を空白で区切った単位の配列で取得できる。
ただし、いちばん最初の要素は、そのアプリケーションのパスそれ自身なので、Skip 拡張メソッドで読み飛ばしておく。早速 LINQ の出番だ。

var args = System.Environment.GetCommandLineArgs().Skip(1);

次に、オプションスイッチの有無を判定する "プチ関数" を書くことにした。
"プチ関数" と勝手に呼んでいるが、実はラムダ式のこと。
メソッドにしたりグローバルに再利用したりする程ではないが、ある局所中にちょっとだけパラメータを変えて数回出現するコード片を、ラムダ式にまとめておくのである。

オプションスイッチは先頭がスラッシュ(/)かハイフン(-)のいずれかで、続いてオプション名が並ぶので、正規表現でチェックすることに。
オプション名の大文字小文字は無視。
ということで、チェック対象の文字列 > オプション名文字列 > 判定結果(true/false) というラムダ式 hasOption を書く。

Func<string,string,boo> hasOption = (input, optionName) => Regex.IsMatch(input, "(/|-)"+optionName,RegexOption.IgnoreCase);

さらに、チェック対象の文字列 > 判定結果(true/false) という、個別のオプションスイッチごとの判定ラムダ式も定義しておく。

Func<string,bool> hasFoo = (input) => hasOption(input, "foo");
Func<string,bool> hasBar = (input) => hasOption(input, "bar");

なんだか関数型プログラミングにおける部分適用みたいでいい感じ。

オプションスイッチの有無の判定だけなら、個別のオプションスイッチごとの判定式まで定義せずとも、hasOption だけで用は足りる。
しかし後述するとおり、オプションスイッチに続く引数を取得するときに、この準備が効いてくるのだ。

オプションスイッチの有無を判定するには Any でチェックすればよい。

if (args.Any(hasFoo)) { /* foo スイッチが指定されていた */ }

さらに、foo スイッチが指定されていたときに続く引数を手に入れるには、SkipWhile で foo スイッチまで読み飛ばし、Skip(1) で foo スイッチそのものを読み飛ばしたら、First() で手に入る。

if (args.Any(hasFoo)) {
　　paramOfFoo = args.SkipWhile(arg => !hasFoo(arg)).Skip(1).First();
}

hasOption式だけでも書けるが、hasFoo 式を先に定義しておくことで、多少読みやすくなっていることと思う。
インテリセンスも効くし。

ということで、以上、LINQ とラムダ式のおかげで、コマンドライン引数解析をどうにかかわすことができた。

皆さんならどう実装するだろう?
「そんなことしなくても、こうやったらできるよ!」「ここでこんなライブラリがあって、使い方もすぐわかるよ!」など、ご指摘あればコメント等頂ければ幸いである。

2010/09/15 追記

@neuecc さんから、ご自身のブログ記事を紹介頂いた。
感謝。

"neue cc - Linqでコマンドラインオプション解析"
http://neue.cc/2009/12/13_229.html

なるほど、GroupBy でオプションスイッチが出現するごとにグループ分けするのだが、グループ分けのキーをラムダ式外部の変数で押さえてクロージャとし、列挙中にどんどんこのキーを書き換えるわけか。
あとは ToDictionary で仕上げ、と。

あと、このブログ記事にて紹介されているライブラリとして、Mono に存在するらしい NDesk.Options が取り上げられている。
http://d.hatena.ne.jp/coma2n/20091210/1260433596

上記記事で、さらに属性ベースでコマンドライン引数の解析ができる CommandlineParser も秀逸。

一筋縄ではいかなかった Microsoft WCat(Web Capacity Analysis Tool) 6.3(x86)

とある事情で、とある Web アプリケーションに、同時にたくさんのリクエストを仕掛けて、クラッシュしたりしないかどうか、実験してみることになった。

ということで思い出したのが、Microsoft がリリースしている無償利用可能な負荷ツール「Web Capacity Analysis Tool」、略して WCat。
設定ファイルやシナリオスクリプトをテキストエディタで記述し、それを読み込ませて動作する、コマンドラインから使うコンソールアプリとなっている。

このへんとかが参考になる。

[HOW TO] 無償の簡易 Web 負荷ツール WCATの使い方
http://bit.ly/9CXTec
（@hirookun さんの IIS フォーラムの投稿）

そこで、早速、WCat を利用して実験してみることにした。

しかしながら、なかなか一筋縄ではいかなかったので、その顛末を以下に記しておく。

WCat の最新バージョンは2010年9月6日現在、6.3 っぽい。
32bit 版は下記からダウンロードできる。
http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1466
もちろん、64bit 版もある。
http://www.iis.net/downloads/default.aspx?tabid=34&i=1467&g=6

今回は諸事情で 32bit 版を使用することに。

WCat は「簡易 Web 負荷ツール」とはいえ、なかなかどうして多機能。
単に負荷をかけるっていうんじゃなくて、パフォーマンスモニタも含めて監視、ロギングしたりできるらしい。
おまけに、ボット的に、中央制御の PC からたくさんの PC にチャイルドプロセスを配布し、こいつらをリモートで起動して、Web サーバーに負荷をかけることができるようになっている。

今回はそこまで凝った使い方はせず、単一のクライアント機だけで、ほどほどのリクエストを送信するようにした。

さてこの WCat だが、Web サーバーと WCat の間に HTTP プロキシがあると使えないっぽい。
付属の Word 文書によるマニュアルを読んでも、settings.ubr にてプロキシの設定を行う設定構文はなさそう。
無理を承知で色々試してみたが、ついにプロキシを超えての実行はできなかった。

まぁ、ストレステストの性質上、間にプロキシが挟まっていると、Web サーバーの負荷テストをしているのか、プロキシの負荷テストをしているのかわからなくなってしまう。
それに、パフォーマンスモニタの監視なども同時に行える WCat の特徴を考えると、妥当な制限かもしれない。

次に、対応しているプラットフォームだが、上記ダウンロードサイトでは、Windows Vista までとの記述になっている。
だが、まぁ、Vista で動くのだから当然と言えば当然だが、Windows 7 Pro(x86) で動作することを確認。

SSL でも問題なし。
home.ubr 側でシナリオを記述するところで、 request { ... } のブロック内に secure = true; の行を書き足しておけばOK。

ところが、どういうわけかはわからないのだが、Hyper-V2.0 上に新規インストールした Windows 7 Pro(x86) 仮想マシンで実行すると、アプリケーションエラーが発生してしまう。
ネットワークアダプタをレガシーにしてみるとか、いろいろ試行錯誤したのだが、どうやってもうまくいかない。

仮想マシンではなく、実機では動作しているので（しかも、まったく構成の異なる2台で成功）、仮想化となにか関係があるのだろうか?
しかしほかの原因が皆無とは言えないので、断言はできない。

さて、同じ Hyper-V2.0 サーバーに、今度は Windows XP Pro SP3(x86) を新規インストールし、統合サービスもセットアップした上で、WCat を試してみた。
するとこちらは成功。
うーん、何なんでしょう。


ところで、実は、Windows XP Pro(x86) 上で WCat をインストール & 動作させるにはコツが要った。

まず、インストーラによるセットアップ作業そのものは問題ない。
問題はそのあと。

WCat では、インストールされた wcat.wsf にパラメータをつけて実行することで、チャイルドプロセスをたくさんの PC にコピーし、いよいよ実行のときにそれら PC 上のチャイルドプロセス群を起動するのに備える（ボットのように）。
今回はクライアントは中央制御機と同じ1機しかないので、この作業を readme.txt に従って次の構文で試してみた。

cscript wcat.wsf -terminate -update -clients localhost

ところが、「パス \\localhost\admin$ が見つからない」的なエラーとなってしまう。

なるほど、たしかに、この WindowsXP 環境では、エクスプローラのアドレスバーに「\\localhost\admin$」と入力しても、その PC 自身は参照されず、"見つからない" エラーとなる。
この WindowsXP 仮想マシンのコンピュータ名が "MyPC1" だとすると、「\\MyPC1\admin$」ならば、ちゃんと成功するので、ネットワーク構成がおかしいわけではなさそう。当然、書き込みもできるので、共有のアクセス権が足りないとかそういう問題でもなさそうである。
ちなみに Windows 7 では、「\\localhost」でちゃんと自身が参照される。

ということで、-clients スイッチに、"localhost" ではなく、きちんと自身のホスト名を書いてやってみた。

cscript wcat.wsf -terminate -update -clients MyPC1

これなら成功。

さて次は、settings.ubr や home.ubr を用意したら、いよいよ実行だ。
というわけで、次のコマンドラインを実行。

cscript wcat.wsf -terminate -run -clients MyPC1 -t home.ubr -f setting.ubr

しかししかし、またしても「パス \\localhost\admin$ が見つからない」的エラーとなる。
えぇ、なぜ?
ちゃんと -clients スイッチに、ホスト名で指定しているのに。

途方に暮れたので、wcat.wsf をテキストエディタで開いてみた。

するとなにやら匂う記述を発見。
wcat.wsf に次の一行が。

var CLIENT_COMMAND_LINE = "\\\\localhost" + TARGET_SHARE + "wcclient.exe";

ロジックをよく見たわけではないが、"localhost" で検索すると、どうにもここが怪しくてしようがない。
変数名も、ズバリ CLIENT_COMMAND_LINE だし。

ということで、ここをズバリ "MyPC1" と書き換えて保存。

var CLIENT_COMMAND_LINE = "\\\\MyPC1" + TARGET_SHARE + "wcclient.exe";

これで実行してみると、ようやく成功した。

　　◇　　◇　　◇　　◇

さて、ちょっと話しは変わって。

WCat は無償利用ながら、先に述べたとおりかなり秀逸なツールである。
（GUIがないので、ある程度理解するまで扱いづらいが）

ただ、パフォーマンスモニタの監視とか、ボット的に多数のクライアント機を中央から起動とか、そこまで凝った使い方ではなく、単にちょっとかるーく負荷をかけてみたい、というときに、WCat は Windows 用のコンソールアプリなので、Windows のライセンスが必要になるのが今回はちょっと厄介だった。
幸い今回は、社内で未使用だったライセンスがあったのでそれを一時借りてしのぐことができたが。

今回の程度の実験なら、Linux 上でも動作する、Apache に付属の "ab" ( Apache Bench ) というツールがあるとのこと。
Linux の適当なディストリビューションを利用して ab を使うのも一案かもしれない。
自分は ab は使ったことがないので、今後の宿題。