第2回 ASP.NETによるCRUD処理（パート1：管理用ページの作成）：連載：ASP.NETによる軽量業務アプリ開発（2/4 ページ）

[arton， ]

Webアプリの作成（appcmdツール）

　最初に前回作成した、C:\inetpub\wwwroot\testディレクトリ以下をWebアプリ化する。ここでのWebアプリとは、IISから見て独自の仮想ディレクトリとアプリケーションプールの割り当てを持つ実行範囲の意味である。

　IISはC:\inetpub\wwwrootディレクトリを既定のルートディレクトリとする。前回作成したtestディレクトリは、C:\inetpub\wwwrootディレクトリの子ディレクトリなので、そのままではルートディレクトリの子ディレクトリとして扱われて、独立したWebアプリとしては処理されない。このため、そのままでは前回作成したC:\inetpub\wwwroot\test\App_Dataディレクトリは、Webアプリのデータディレクトリとして扱われない*3。そこで、C:\inetpub\wwwroot\testディレクトリをWebアプリ化する必要があるのだ。

*3　testディレクトリをWebアプリとしなかった場合、testディレクトリに配置するASPXファイル（ここではadmin.aspxファイル）で指定する「"Data Source=.\\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|testdb.mdf;User Instance=true"」という接続文字列内の「|DataDirectory|」という特殊なディレクトリの指定子は、C:\inetpub\wwwroot\App_Dataディレクトリを示すことになる。これはWebアプリの起点となるディレクトリがC:\inetpub\wwwrootディレクトリのままだからだ。この場合、せっかく作成した「test\App_Data」ディレクトリは、単にtestディレクトリの子ディレクトリ以上の意味を持たず「DataDirectory」という特殊なディレクトリとしては扱われない。ただし、IISはApp_Dataというディレクトリ名については既定で非公開ディレクトリ扱いする。このため単なる子ディレクトリではあるが、作成したApp_Dataディレクトリを/test/App_Data/というURIでアクセスできるわけではない。

　特定のディレクトリを独立したWebアプリとしてIISに扱わせるには、appcmd.exeコマンドラインツール（以降はappcmdと表記）を利用する。

　このツールは、C:\Windows\System32\inetsrvディレクトリにインストールされている。PowerShellの既定のセットアップではこのディレクトリはPATHには含まれていないため、利用時にはこのディレクトリに移動してファイル名を直接指定するか、フルパス名で指定するか、別途PATH環境変数に設定する必要がある。

　以下に、管理者用PowerShellでの実行例を示す（管理者としてPowerShellを実行する必要があることに注意）。前回同様、プロンプトは「>」で示す。

　なお、コマンドプロンプトと異なり、PowerShellはカレントディレクトリのコマンドを実行する場合に「.\」を必要とする。また拡張子の「.exe」を省略できるのはコマンドプロンプトと同様である。

> cd c:\windows\system32\inetsrv
> .\appcmd add app /site.name:"Default Web Site" /path:/test /physicalPath:c:\inetpub\wwwroot\test
APP オブジェクト "Default Web Site/test" を追加しました
VDIR オブジェクト "Default Web Site/test" を追加しました

appcmdを実行してWebアプリを登録する

　上で指定している「"Default Web Site"」は、IISの既定のWebサイトだ。名前に空白が入っているため「""」で囲む必要がある。IISは複数のサイトをサポートしているため、必ずどのサイトを対象とするかの指定が必要である。

　ちなみに、削除する場合は以下のように指定する。

> .\appcmd delete app "Default Web Site/test"
APP オブジェクト "Default Web Site/test" は削除されました

appcmdを実行してWebアプリを削除する

　上の例で削除しているのは、あくまでもIISに登録されたWebアプリである。つまりファイルシステム上のC:\inetpub\wwwroot\testディレクトリとその下にあるディレクトリやファイルは影響を受けない。

　このため、もし「appcmd delete 〜」コマンドを実行しても、再度「appcmd add 〜」コマンドを実行することでWebアプリに戻せる。

［コラム］appcmdの説明

　appcmdを利用して、IISの仮想サイト、仮想ディレクトリ、WebアプリおよびWebアプリのプロセスに相当するアプリケーションプールなどの登録／削除、有効／無効などを設定できる。

　appcmdは、以下の形式で実行する。

appcmd コマンド 対象 パラメーター

appcmdの構文

　コマンドには本文で示したadd、delete以外にもlistなどがある。また対象にはapp以外にsite、apppoolなどがある。

　appcmdに「/?」を指定して実行することで、これらのコマンドや対象を調べられる。

コマンド	説明
appcmd /?	コマンド全体のヘルプ
appcmd 対象 /?	指定した対象ごとのヘルプ
appcmd コマンド 対象 /?	指定した対象に対するコマンドのヘルプ
appcmdのヘルプコマンド

　以上でtestディレクトリのWebアプリ化は完了した。

　これにより、このディレクトリへ配置するASPXファイルは、testというWebアプリに属することになる。また、前回作成したApp_DataディレクトリはこのWebアプリ固有のデータ格納ディレクトリとして利用される。

［コラム］コマンドラインツール補足

　IISそのものを開始／停止するには、管理者コマンドプロンプトかPowerShellからnetコマンドを実行する。

• IISの停止
  　　− net stop w3svc
• IISの開始
  　　− net start w3svc

　前回、データベースファイル（.mdfファイル）をプロセス固有のものとして作成した。

　このため、PowerShellなどの他のプロセスからIISと同時に利用はできない。もし利用したい場合は、上記コマンドでIISを停止する方法が簡単だ。

　このとき、IISは止めずにtestというWebアプリのみを停止したい場合には、前述のappcmdとapppoolを利用し、以下のように実行して、testに割り当てたアプリケーションプールを停止する。

appcmd stop apppool DefaultAppPool

指定したアプリケーションプールのみを停止するコマンド

　この例だと、アプリケーションプールのstopにより、DefaultAppPoolを利用するWebアプリが停止されるため、そのWebアプリが利用していた.mdfファイルを他のプロセスがアタッチ可能となる。このとき、DefaultAppPool以外のアプリケーションプールを利用するWebアプリは実行を継続できる。

　アプリケーションプールの実行を再開するには、startを指定する。

appcmd start apppool DefaultAppPool

アプリケーションプールの実行を再開するコマンド

　上の例ではtestに特定のアプリケーションプールを割り当てていないため、既定で割り当てられるDefaultAppPoolを指定した。細かくWebアプリごとに停止、開始を切り替えるのであれば、個々のWebアプリごとに異なるアプリケーションプールを作成し割り当ててもよいだろう。これらの操作についてもappcmdを利用する。なお、詳細はappcmdのヘルプなどを参照いただきたい。

　次に、testディレクトリに配置するASPXファイルの構文について簡単に見ておこう。

ASPXファイルの構文

　ASP.NETの埋め込みHTML（ASPXファイル）は、以下の構文を利用して記述する。なお、ここで紹介するのは本記事のサンプルソースコードの読解に必要となる必要最小限のものである。

ディレクティブ

　ASPXファイルでは以下のディレクティブを使用して、各種の設定を行える（通常はファイルの先頭部で行う）。

• Pageディレクティブ
  　　− 「<%@ Page パラメーター %>」の形式で、このASPXファイルのプログラムとしての扱い方を指定する
• Importディレクティブ
  　　− 「<%@ Import namespace="ネームスペース名" %>」の形式で、このASPXファイル内で名前空間による修飾なしで記述するクラスを指定する。C#プログラムのusingステートメントに相当する

　その他のディレクティブについてはMSDNの「テキスト テンプレートのディレクティブの構文」を参照のこと。

コード表示ブロック

　ASPXファイルでは通常、コード表示ブロックを使ってインラインコードもしくはインライン式の形でコードを記述していく。

• インラインコード
  　　− ASPXファイル中のプログラムは「<%」と「%>」（＝いわゆるコードナゲット）で囲まれた範囲に記述する。インラインコードは、ASP.NETによるページのコンパイル中に暗黙裏に生成されるクラスの1つのメソッドとして実現される。このため、内部にメソッドやクラスを定義することはできない*4

*4　インラインではない、独立したソースコードの記述が必要な場合は、「コード宣言ブロック」や「サーバー側インクルード」を利用する

• インライン式
  　　− インライン式は「<%=」と「%>」で囲まれた範囲の式の実行結果のオブジェクトを文字列としてHTMLコードに埋め込む

［コラム］これでよいのか？

　インラインコードの説明から分かるように、単純に埋め込みHTMLを記述すると、上から下へ流れるプログラムとならざるを得ない。これは次のプログラミングの禁じ手に抵触する。

• ソースコードの重複
  　　− 複数箇所で実行する必要があるコードを、都度埋め込むため、ソースコードの重複を招く
• 深いブロックのネスト
  　　− 複数条件で順にフィルタリングする場合、途中で別ルーチンに分けることができないため、ブロックが深くなる

　当然、これらは避けるべきであるが、本連載の趣旨ではこうした事態を避けるべきかどうかは「ケースバイケース」だということになる。

　例えば、次節で示す管理用ページのソースコード（admin.aspxファイル）は9ブロックのネストとなり、しかもディレクティブの切れ目が多数入るため、読みやすいか読みにくいかの二元論であれば読みにくい。実際、サンプルコードの作成中に、ブロックの終端の「}」を忘れてコンパイルエラーとなった（普通のエディターで開発したので自動かっこ挿入を利用していないという面もある）。

　にもかかわらず、コンパイルエラーが発生してからコードを修正して再コンパイルされるまでのフィードバックの速さから、作成速度についてのトレードオフはない。むしろ「編集」→「上書き保存」→「ブラウザーから読み込み」のフィードバックサイクルの速さからは高速だとすらいえる。

　埋め込みHTMLの利点は、保守性ではなく、開発開始から公開までの速度にある。ただしWebアプリというリモートインターフェースを伴うものなので、限定された公開範囲と期間を対象としたものにのみ適用すべきである。

　つまり、第1回の冒頭で説明したように、埋め込みHTMLによる開発はLL（軽量）言語によるスクリプティング（シェルプログラミング）に相当する。

HTML

　ASPXファイル上のディレクティブ、コード表示ブロック以外、つまり<%で始まり%>で終わるタグ以外の部分は、全て直接クライアントへ送られる。

　従ってHTMLは、<%〜%>以外の部分に記述する。

　以上のことを踏まえて、管理用ページの実装について見ていこう。