連載 ASP.NET 2.0が変えるWebアプリ開発の世界 第1回 周辺技術が支えるASP.NET 2.0の進化 山田 祥寛 2004/09/29
Page1 Page2 Page3 Page4

.NET Framework 2.0における新機能

　次に、.NET Framework 2.0における新機能のうち、主にASP.NETアプリケーションの運用・管理にかかわる部分について概観することにしよう。.NET Framework 2.0のポイントとしては、当然ながらクラス・ライブラリの拡張も見逃せないところであるが、これらについては、次回以降であらためて詳述することとしたい。

●アプリケーションの「事前コンパイル」

　.NET Framework 2.0では先述の「XCOPY的な配置」に加え、アプリケーションをプリ・コンパイル（事前コンパイル）するための機能が追加された。

　諸兄もすでにご存じのとおり、ASP.NET 1.xの「.aspx」ファイルは初回のリクエスト時に自動的にコンパイル処理される。「.aspx」ファイルが更新された場合にも、タイムスタンプから動的に再コンパイル処理を行うので、アプリケーション開発者はコンパイルという処理を何ら意識することもなく、ASP.NETアプリケーションの開発を行うことができたというわけだ。

　ASP.NET 2.0でも動的コンパイルの機能は有効であるが、動的コンパイルにはいくつかの問題点もある。

（1）第三者がソース・コードを判読／改変できる

　ソース・コードとは、アプリケーションそのものを販売するベンダにとっては、知的財産の集積であり、付加価値の源泉でもある。しかし、動的コンパイルを利用した場合、ソース・コードの中身はまったく保護されないので、第三者（例えば、アプリケーションを購入した企業）がコードの一部を自分のアプリケーションに転用したり、オリジナルのコードを改変したりすることも自由にできてしまう。これは、ビジネスとしてASP.NETを採用・利用することに対する大きな阻害要因となり得るものだ。

　もちろん、コードビハインド方式を採用すれば、この問題もある程度は解決することができるが、それでも「.aspx」ファイルそのものを隠ぺいする手段はない。また、そもそもコードを隠ぺいするためだけにコードビハインド方式を採用しなければならないというのも、なんとも本末転倒な話だろう。

（2）コンパイル処理を介するため、初回リクエスト時に処理速度が低下する

　先述したように、ASP.NETは「.aspx」ファイル更新後の初回リクエスト時に（再）コンパイル処理を行う。そのため、ASP.NETアプリケーションを初回に起動する際には、どうしても処理パフォーマンスが遅くなりがちだ。もちろん、その後、何百回、何千回とリクエストが行われることを考えれば、初回処理の遅延などは取るに足らない問題ではあるだろう。しかし、開発時には、意外とこの初回のコンパイル時間がストレスになるものだった。

（3）コンパイル・エラーが実行のタイミングまで発覚しない可能性がある

　十分なテストが行われていれば、本番環境でコンパイル・レベルのエラーが発生することはまず考えにくいが、開発者も人の子。当然、コードの修正などに際して、つまらないケアレスミスを起こすことは十分にあり得る。しかし、動的コンパイル方式を採用している場合には、実行時までコンパイルが行われないので、ケアレスミスの発覚が遅延する可能性があった。

　以上のような問題も、事前コンパイルを行うことですべて解決される。例えば、以下のようなフォルダ構成のアプリケーションがあったとしよう。

　これを事前コンパイルすると、以下のようなフォルダ／ファイルが生成される。

　事前コンパイル後のDefault.aspxの中身は、「This is a marker file generated by the precompilation tool, and should not be deleted!」というダミーの文字列のみが書かれた、内容的には空のファイルだ。Default.aspxの実体は、アセンブリ（「.dll」ファイル）として「/bin」フォルダに格納される。同じく「/bin」フォルダに格納された「.compiled」ファイルによって、リクエスト・パスとコンパイル済みのアセンブリが動的にマッピングされることとなる。つまり、事前コンパイルにおいては、コンパイル可能なすべてのソース・コードはアセンブリに格納され、ソース・コードそのものは配置の対象から除外されることとなる。

　これによって、原則的に第三者が生のソース・コードを参照／改変することはできなくなるし、実行時にはコンパイル済みのコードを直接に処理できるので、初回アクセス時のストレスも軽減できる。また、当然、事前コンパイルを介することで実行時にコンパイル・レベルのエラーが発生する可能性は根絶できる。

［注意］

中身を持たない「.aspx」ファイルは（「.aspx」ファイル内のコメントを見ても分かるように）削除してはならない。これは、「.aspx」ファイルのように直接リクエストされるファイルについては、ファイルそのものの存在チェックが行われる可能性があるためだ。中身がないからといって、不用意にファイルを削除してしまうと、アプリケーションが正常に動作しなくなる場合があるので注意すること。 　また、もしも開発環境上で事前コンパイルを行い、後から本番環境にアプリケーションをXCOPYするという場合には、開発／本番環境の双方で仮想ディレクトリの名前を等しく設定する必要がある。これは、先述の「.compiled」ファイルに仮想ディレクトリ名も含めた記述があるためだ。仮想ディレクトリ名を変更してしまうと、アプリケーション自体が正常に動作しなくなってしまう。

　それでは、以下に事前コンパイルを行うための方法をいくつか挙げておくことにしよう。事前コンパイルを行う最も簡単な方法は、VS 2005のメニューから［Webサイト］−［Webの公開］を選択することだ。これにより、次の画面のような［Webの公開］ダイアログが表示される。このダイアログでは、Web上での公開先を指定するだけで、現在のプロジェクトの内容を事前コンパイル・配置することができる。

［Webの公開］ダイアログ

公開場所には、Webサイトのほか、FTPサーバ、ファイル共有、ローカルのファイルシステムなどを指定することができる。単純なXCOPY方式の配置を行いたい場合には、先述の「Microsoft Deployment Environment」が利用できる。

　ただし、ここで誤解していただきたくないのは、事前コンパイルの機能はあくまで.NET Framework 2.0で提供されている機能であるということだ。つまり、必ずしもVS 2005からでなくても、事前コンパイルを実行することができる。以下に、その2つの方法を紹介しておこう。

＜方法1＞ コマンドラインからの事前コンパイルの実行

　.NET Framework SDK 2.0には、aspnet_compilerというコマンドが用意されている（格納先は「%SystemRoot%\Microsoft.NET\Framework\v2.0.40607」）。VS 2005における［Webの公開］は、このaspnet_compilerコマンドをIDE上から実行できるようにしたものにすぎない。例えば、コマンド・プロンプトから以下のコマンドを入力してみよう。

> aspnet_compiler -v sample -p C:\WebSites\sample c:\sample

　この場合、「C:\WebSites\sample」に格納された一連のファイルを事前コンパイルし、c:\sampleにその結果を出力する。-vオプションで指定されている「sample」は、仮想ディレクトリ名である。

　このコマンドラインを実行した結果が、次の画面である。

aspnet_compilerコマンドの実行結果

＜方法2＞ ASP.NETアプリケーションからの事前コンパイルの実行

　aspnet_compilerコマンドが配置のタイミングで合わせて事前コンパイルを行うタイプのものであるのに対して、こちらの方法はすでにXCOPY方式で配置してしまったアプリケーションを事前コンパイルするようなケースで有効だ。実行方法は単純で、ブラウザから以下のURLをリクエストするだけでよい。

http://localhost/＜仮想ディレクトリ名＞/precompile.axd

　precompile.axdはHTTPハンドラ・クラスによって実現されたファントム・リソースで、仮想ディレクトリ上に実体が用意されているわけではない（HTTPハンドラ・クラスに関する詳細は「.NET TIPS：特定の拡張子に対するアクセスを制限するには？」を参照いただきたい）。

　以下のようなメッセージが表示されれば、事前コンパイル処理は成功だ。

precompile.axdの実行結果（成功）

　なお、precompile.axdによる事前コンパイルでは、aspnet_compilerコマンドのように、仮想ディレクトリ直下のファイルを再編するわけでは「ない」点に注意していただきたい。あくまで、precompile.axdは通常の動的コンパイル処理をアプリケーション全体でまとめて行うにすぎない。従って、コンパイル結果もデフォルトのテンポラリ・フォルダである「%SystemRoot%\Microsoft.NET\Framework\v2.0.40607\Temporary ASP.NET Files」フォルダ配下に格納されるだけだ。生のソース・コードをサーバ上から取り除きたい、という目的のためには、aspnet_compilerコマンドを使用する必要がある。

【コラム】動的コンパイルに関する変更 　事前コンパイルという新しい機能が提供されても、従来の動的コンパイル機能は健在だ。のみならず、ASP.NET 2.0ではよりその機能が強化されている。 　従来のASP.NET 1.xにおいて、動的コンパイルが対象とするのは、ASP.NETに直接関連する「.aspx」や「.ascx」などのファイルのみであった。つまり、「.vb」や「.cs」など、自前で用意するライブラリについては、手動でコンパイル処理し、仮想ディレクトリ直下の「/bin」フォルダに配置する必要があった。しかし、ASP.NET 2.0では予約フォルダとして、新たに「/code」フォルダが追加された。「.vb」や「.cs」のように従来は手動コンパイルが必要であったものは、すべてこの「/code」フォルダに保存しておけばよい。すると、実行時に動的コンパイルが有効になるというわけだ。 　これによって、トライ＆エラーによる開発は、より容易になる。

　.NET Framework 2.0では、サイト管理についても強化された。次に、サイト管理に関する新機能について見ていこう。

INDEX
	ASP.NET 2.0が変えるWebアプリ開発の世界
	第1回 周辺技術が支えるASP.NET 2.0の進化
	1．Visual Studio 2005新機能「簡易Webサーバ」と「配置」
	2．Visual Studio 2005新機能「インテリセンス」と「構成」
	3．.NET Framework 2.0新機能「事前コンパイル」
	4．.NET Framework 2.0新機能「サイト管理」

　

「ASP.NET 2.0が変えるWebアプリ開発の世界」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）