Web サイトを事前コンパイルする (C#)

作成者: Scott Mitchell

Visual Studio では、ASP.NET 開発者のために、Web アプリケーション プロジェクト (WAP) と Web サイト プロジェクト (WSP) の 2 種類のプロジェクトが用意されています。 これら 2 種類のプロジェクトの主な違いの 1 つは、WSP ではコードを Web サーバーで自動的にコンパイルできるのに対し、WAP ではデプロイ前にコードを明示的にコンパイルする必要があるということです。 それでも、デプロイ前に WSP をプリコンパイルすることもできます。 このチュートリアルでは、プリコンパイルの利点について説明し、Visual Studio 内とコマンド ラインから Web サイトをプリコンパイルする方法について説明します。

はじめに

Visual Studio では、ASP.NET 開発者のために、Web アプリケーション プロジェクト (WAP) と Web サイト プロジェクト (WSP) の 2 種類の異なるプロジェクトが用意されています。 これらのプロジェクトの種類の主な違いの 1 つは、WAP では明示的なコンパイルが必要であるのに対し、WSP では既定で自動コンパイルが使用されることです。 WAP では、Web アプリケーションのコードを 1 つのアセンブリにコンパイルし、Web サイトの Bin フォルダーに作成します。 デプロイでは、プロジェクトのマークアップ コンテンツ (.aspx.ascx および .master ファイル) を Bin フォルダーのアセンブリと共にコピーする必要があります。分離コード クラス ファイル自体をデプロイする必要はありません。 一方、WSP のデプロイでは、マークアップ ページとそれに対応する分離コード クラスの両方を運用環境にコピーします。 分離コード クラスは、Web サーバー上でオンデマンドでコンパイルされます。

自動コンパイル オプションは簡単に使用できます。 コンパイルの明示的な手順はなく、変更されたファイルのみをデプロイする必要があります。一方、明示的なコンパイルでは、変更されたマークアップ ページとコンパイルしたアセンブリの両方をデプロイする必要があります。 ただし、自動デプロイには、次の 2 つの潜在的な欠点があります。

• 最初にページにアクセスしたときに、それらのページを自動でコンパイルする必要があるため、デプロイ後に初めて ASP.NET ページを要求すると、短いものの、気になる長さの遅延が生じる可能性があります。
• 自動コンパイルでは、宣言型マークアップとソース コードの両方が Web サーバー上に存在する必要があります。 Web アプリケーションを Web サーバーにインストールする顧客に販売することを計画している場合、これはお勧めできません。

上記の 2 つの欠点のいずれかが重大な問題となる場合、WAP モデルに切り替えるか、デプロイの前に WSP をプリコンパイルすることができます。 このチュートリアルでは、ホストされる Web サイトに最適なプリコンパイル オプションを調べ、そのプリコンパイル プロセスとプリコンパイルした Web サイトのデプロイについて説明します。

ASP.NET コード生成とコンパイルの概要

使用可能なプリコンパイル オプションを示す前に、まず ASP.NET ページが作成または最後に更新されてから初めて要求されたときに発生するコード生成とコンパイルについて説明します。 ご存知のように、ASP.NET ページは、.aspx ファイル内の宣言型マークアップと、通常は別の分離コード クラス ファイル (.aspx.cs) 内のソース コード部分の 2 つの部分で構成されています。 ASP.NET ページが要求されたときにランタイムによって実行される手順は、アプリケーションのコンパイル モデルによって異なります。

WAP では、デプロイする前に、ページのソース コードを 1 つのアセンブリに明示的にコンパイルする必要があります。 デプロイ時に、このアセンブリとさまざまなマークアップ ページが運用環境にコピーされます。 ASP.NET ページの要求が Web サーバーに到着すると、ランタイムはページの分離コード クラスのインスタンスを作成し、その ProcessRequest メソッドを呼び出します。このメソッドはページのライフサイクルを開始し、最終的には、要求元に返されるページのコンテンツを生成します。 デプロイ前に分離コード クラスが既にアセンブリにコンパイルされているため、ランタイムは ASP.NET ページの分離コード クラスを操作できます。

WSP と自動コンパイルでは、デプロイ前の明示的なコンパイル手順はありません。 代わりに、デプロイでは、宣言とソース コード コンテンツの両方を運用環境にコピーする必要があります。 ページが作成または最後に更新されてから初めて、ASP.NET ページの要求が Web サーバーに到着した場合、ランタイムは最初に分離コード クラスをアセンブリにコンパイルする必要があります。 このコンパイル済みアセンブリは %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files フォルダーに保存されますが、<system.web> の <compilation tempDirectory="" /> 要素 (通常は Web.config で指定) を介してこのフォルダーの場所をカスタマイズできます。 アセンブリはディスクに保存されるため、同じページに対する後続の要求で再コンパイルする必要はありません。

つまり、明示的なコンパイルでは、デプロイ前に Web サイトのソース コードをコンパイルする必要があり、ランタイムがその手順を実行する必要がなくなります。 自動コンパイルでは、ランタイムはページのソース コードのコンパイルを処理しますが、ページが作成または最後に更新されてから初めてアクセスする際に、初期化に要するわずかな時間がかかります。

しかし、ASP.NET ページ (.aspx ファイル) の宣言部分はどうでしょうか。 宣言型マークアップで定義されている Web コントロールはコード内でアクセス可能であるため、分離コード クラス内の .aspx ファイルとコードの間に関係があることは明らかです。 また、.aspx ファイル内のコンテンツが、ページによって生成されるレンダリングされたマークアップに大きく影響することも明らかです。 では、ランタイムは、要求されたページの表示コンテンツを生成するために、テキスト、HTML、および .aspx ファイルで定義されている Web コントロールの構文をどのように処理するでしょうか。

ここでは、WAP と WSP の間で異なる、実装の詳細を細かく扱って脇道にそれるようなことはしませんが、端的に言うと、ランタイムは保護されたメンバーとメソッドとしてさまざまな Web コントロールを含むクラス ファイルを自動的に生成します。 この生成されたファイルは、部分クラスとして、対応する分離コード クラスに実装されます (部分クラスは、1 つのクラスのコンテンツを複数のファイルに分散できます)。そのため、分離コード クラスは、作成する .aspx.cs ファイルと、ランタイムによって作成されたこの自動生成クラスの 2 つの場所で定義されます。 この自動生成されたクラスは、%WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files フォルダーに格納されます。

ここで重要なのは、ランタイムによって ASP.NET ページをレンダリングするには、宣言とソース コードの両方の部分をアセンブリにコンパイルする必要があるということです。 WAP では、デプロイ前にソース コードがアセンブリに明示的にコンパイルされますが、宣言型マークアップは引き続きコードに変換され、Web サーバー上のランタイムによってコンパイルされる必要があります。 自動コンパイルを使用する WSP では、ソース コードと宣言型マークアップの両方を Web サーバーでコンパイルする必要があります。

WSP モデルで明示的なコンパイルを使用できます。 WAP モデルと同様に、ソース コード部分を明示的にコンパイルできます。 さらに、宣言型マークアップをコンパイルすることもできます。

プリコンパイル オプション

.NET Framework には、WSP モデルを使用して構築された ASP.NET アプリケーションのソース コード (およびコンテンツ) をコンパイルできる ASP.NET コンパイル ツール (aspnet_compiler.exe) が付属しています。 このツールは .NET Framework バージョン 2.0 でリリースされ、%WINDIR%\Microsoft.NET\Framework\v2.0.50727 フォルダーにあります。コマンド ラインから使用することも、Visual Studio 内から [ビルド] メニューの [Web サイトの発行] オプションを使用して起動することもできます。

コンパイル ツールには、インプレース プリコンパイルとデプロイのプリコンパイルという 2 つの一般的な形式のコンパイルが用意されています。 インプレース プリコンパイルでは、コマンド ラインから aspnet_compiler.exe ツールを実行し、コンピューター上にある Web サイトの仮想ディレクトリまたは物理パスへのパスを指定します。 その後、コンパイル ツールはプロジェクト内の各 ASP.NET ページをコンパイルし、各ページがブラウザーから初めてアクセスされた場合と同様に、コンパイル済みバージョンを %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files フォルダーに格納します。 インプレース プリコンパイルでは、ランタイムでこの手順を実行する必要が軽減されるため、サイトに新しくデプロイされた ASP.NET ページに対する最初の要求をすばやく処理できます。 ただし、インプレース プリコンパイルは、Web サーバーのコマンド ラインからプログラムを実行できる必要があるため、ホストされている Web サイトの大部分では使用できません。 共有ホスティング環境では、このレベルのアクセスは許可されません。

Web サイト内のページを Temporary ASP.NET Files フォルダーにコンパイルする代わりに、デプロイのプリコンパイルを使用して、選択したディレクトリに、運用環境にデプロイできる形式でページをコンパイルできます。

このチュートリアルで説明するデプロイのプリコンパイルには、更新可能なユーザー インターフェイスを使用したプリコンパイルと、更新不可能なユーザー インターフェイスを使用したプリコンパイルの 2 種類があります。 更新可能なユーザー インターフェイスを使用したプリコンパイルでは、宣言型マークアップが .aspx、.ascx、.master ファイルに残されるため、開発者は運用環境サーバー上の宣言型マークアップを表示したり、必要に応じて変更したりできます。 更新不可能なユーザー インターフェイスを使用したプリコンパイルでは、コンテンツのない .aspx ページが生成され、.ascx と .master ファイルが削除されるため、宣言型マークアップが非表示になり、開発者が運用環境から変更できなくなります。

更新可能なユーザー インターフェイスを使用したデプロイのプリコンパイル

デプロイのプリコンパイルを理解する最善の方法は、実際の例を確認することです。 更新可能なユーザー インターフェイスを使用して、ブック レビュー WSP をデプロイ用にプリコンパイルしてみましょう。 ASP.NET コンパイル ツールは、Visual Studio の [ビルド] メニューまたはコマンド ラインから呼び出すことができます。 このセクションでは、Visual Studio 内からツールを使用する方法について説明します。「コマンド ラインからのプリコンパイル」セクションでは、コマンド ラインからコンパイラ ツールを実行する方法を扱います。

Visual Studio でブック レビュー WSP を開き、[ビルド] メニューに移動し、[Web サイトの発行] メニュー オプションを選択します。 これにより、[Web サイトの発行] ダイアログ ボックス (図 1 を参照) が起動します。このダイアログ ボックスでは、ターゲットの場所、プリコンパイル済みサイトのユーザー インターフェイスが更新可能かどうか、その他のコンパイラ ツール オプションを指定できます。 ターゲットの場所には、リモート Web サーバーや FTP サーバーを指定できますが、ここではコンピューターのハード ドライブ上のフォルダーを選択します。 更新可能なユーザー インターフェイスを使用してサイトをプリコンパイルする場合は、[このプリコンパイル済みサイトを更新可能にする] チェックボックスをオンのままにして、[OK] をクリックします。

図 1: ASP.NET コンパイル ツールは、指定されたターゲットの場所に Web サイトをプリコンパイルします
(クリックするとフルサイズの画像が表示されます)

Web サイトをプリコンパイルしたら、[Web サイトの発行] ダイアログ ボックスで入力したターゲットの場所に移動します。 少し時間を取って、このフォルダーの内容と Web サイトの内容を比較しましょう。 図 2 は、ブック レビュー Web サイト フォルダーを示しています。 .aspx と .aspx.cs ファイルの両方が含まれていることに注目してください。 また、Bin ディレクトリには、前のチュートリアルで追加した Elmah.dll ファイルが 1 つだけ含まれていることに注目してください。

図 2: プロジェクト ディレクトリに含まれる .aspx と .aspx.cs ファイル。Bin フォルダーには Elmah.dll のみが含まれています
(クリックするとフルサイズの画像が表示されます)

図 3 は、ASP.NET コンパイル ツールによってコンテンツが作成されたターゲットの場所フォルダーを示しています。 このフォルダーには分離コード ファイルは含まれていません。 さらに、このフォルダーの Bin ディレクトリには、Elmah.dll アセンブリに加えて、いくつかのアセンブリと 2 つの .compiled ファイルが含まれています。

図 3: ターゲットの場所フォルダーにデプロイ用のファイルが含まれています
(クリックするとフルサイズの画像が表示されます)

WAP での明示的なコンパイルとは異なり、デプロイ プロセスのプリコンパイルでは、サイト全体の 1 つのアセンブリは作成されません。 代わりに、複数のページをまとめて各アセンブリにバッチ処理します。 また、Global.asax ファイル (存在する場合) も、App_Code フォルダーのクラスと同様に、独自のアセンブリにコンパイルされます。 ASP.NET Web ページ、ユーザー コントロール、マスター ページ (.aspx、.ascx、.master ファイル) の宣言型マークアップを保持するファイルは、そのままターゲットの場所ディレクトリにコピーされます。 同様に Web.config ファイルは、イメージ、CSS クラス、PDF ファイルなどの静的ファイルと共に直接コピーされます。 コンパイル ツールがさまざまなファイルの種類を処理する方法の詳細については、「ASP.NET プリコンパイル中のファイル処理」を参照してください。

ターゲットの場所ディレクトリには、プリコンパイル済み Web プロジェクトの一部ではないファイル (具体的には PrecompiledApp.config) も含まれています。 このファイルは、アプリケーションがプリコンパイルされたこと、また更新可能な UI と更新不可能な UI のどちらを使用してプリコンパイルされたかを ASP.NET ランタイムに通知します。

最後に、Visual Studio または任意のテキスト エディターを使用して、ターゲットの場所にある .aspx ファイルの 1 つを開きます。 更新可能なユーザー インターフェイスを使用してデプロイをプリコンパイルする場合、ターゲットの場所ディレクトリの ASP.NET ページには、Web サイト内の対応するファイルとまったく同じマークアップが含まれます。

更新不可能なユーザー インターフェイスを使用したデプロイのプリコンパイル

ASP.NET コンパイラ ツールで、更新不可能な UI を使用してデプロイするサイトのプリコンパイルを行うこともできます。 更新不可能な UI を使用したサイトのプリコンパイルは、更新可能な UI でのプリコンパイルとよく似ています。主な違いは、ターゲット ディレクトリ内の ASP.NET ページ、ユーザー コントロール、マスター ページがマークアップから削除されることです。 更新不可能な UI を使用して Web サイトをデプロイ用にプリコンパイルするには、[ビルド] メニューから [Web サイトの発行] オプションを選択しますが、[このプリコンパイル済みサイトを更新可能にする] オプションをオフにします (図 4 を参照)。

図 4: [このプリコンパイル済みサイトを更新可能にする] オプションをオフにして、更新不可能な UI でプリコンパイルします
(クリックするとフルサイズの画像が表示されます)

図 5 は、更新不可能なユーザー インターフェイスを使用してプリコンパイルした後のターゲットの場所フォルダーを示しています。

図 5: 更新不可能な UI を使用したデプロイのターゲットの場所フォルダー
(クリックするとフルサイズの画像が表示されます)

図 3 と図 5 を比較します。 2 つのフォルダーは同じように見えるかもしれませんが、更新不可能な UI フォルダーにはマスター ページ Site.master がないことに注目してください。 図 5 にはさまざまな ASP.NET ページが含まれていますが、これらのファイルの内容を表示すると、宣言型マークアップが削除され、プレースホルダー テキスト "これはプリコンパイル ツールによって生成されたマーカー ファイルです。削除しないでください" に置き換えられていることがわかります。

図 5: 宣言型マークアップが ASP.NET ページから削除されています

図 3 と図 5 の Bin フォルダーは、大幅に異なります。 図 5 の Bin フォルダーには、アセンブリに加えて、各 ASP.NET ページ、ユーザー コントロール、マスター ページの .compiled ファイルが含まれています。

更新不可能な UI を使用してサイトをプリコンパイルする方法は、運用環境で Web サイトをインストールまたは管理するユーザーや会社によって、ASP.NET ページのコンテンツが変更されにないようにしたい場合に役立ちます。 顧客が自分の Web サーバーにインストールするための ASP.NET Web アプリケーションを構築する場合は、納品した .aspx ページを顧客が直接編集してサイトの外観を変更できないようにすることができます。 更新不可能な UI を使用して Web サイトをプリコンパイルすることで、プレースホルダー .aspx ページがインストールの一部として配布されるため、顧客がコンテンツを調べたり変更したりできなくなります。

コマンド ラインからのプリコンパイル

Visual Studio の [Web サイトの発行] ダイアログ ボックスは、ASP.NET コンパイル ツール (aspnet_compiler.exe) を呼び出して Web サイトをプリコンパイルします。 または、コマンド ラインからこのツールを呼び出すこともできます。 Visual Web Developer の [ビルド] メニューに [Web サイトの発行] オプションが含まれていないので、Visual Web Developer を使用する場合は、コマンド ラインからコンパイラ ツールを実行する必要があります。

コマンド ラインからコンパイラ ツールを使用するには、まずコマンド ラインにドロップし、フレームワーク ディレクトリ %WINDIR%\Microsoft.NET\Framework\v2.0.50727 に移動します。 次に、コマンド ラインに次のステートメントを入力します。

aspnet_compiler -p "physical_path_to_app" -v / -f -u "target_location_folder"

上記のコマンドは、ASP.NET コンパイラ ツール (aspnet_compiler.exe) を起動し、-p スイッチを使用して、physical_path_to_app をルートとして Web サイトをプリコンパイルするように指示します。この値は C:\MySites\BookReviews のようになり、引用符で区切る必要があります。

-v スイッチは、サイトの仮想ディレクトリを指定します。 サイトが IIS メタベースの既定の Web サイトとして登録されている場合は、-p スイッチを省略し、アプリケーションの仮想ディレクトリのみを指定できます。 -p スイッチを使用する場合、-v スイッチに先行する値は Web サイトのルートを示し、アプリケーションのルート参照の解決に使用されます。 たとえば、値 -v /MySite を指定した場合、アプリケーションの ~/path/file への参照は、~/MySite/path/file として解決されます。 ブック レビュー サイトは Web ホスティング会社のルート ディレクトリにあるため、スイッチ -v / が使用されています。

-f スイッチが存在する場合、target_location_folder ディレクトリが既に存在すると、それを上書きするようにコンパイル ツールに指示します。 -f スイッチを省略した場合、ターゲットの場所フォルダーが既に存在すると、コンパイル ツールは、"エラー ASPRUNTIME: ターゲット ディレクトリが空ではありません。 手動で削除するか、別のターゲットを選択してください。" というエラーで終了します。

-u スイッチが存在する場合は、更新可能なユーザー インターフェイスを作成するようにツールに通知します。 更新不可能なユーザー インターフェイスを使用してサイトをプリコンパイルするには、このスイッチを省略します。

最後に、target_location_folder はターゲットの場所ディレクトリへの物理パスです。この値は C:\MySites\Output\BookReviews のようになり、引用符で区切る必要があります。

プリコンパイル済み Web サイトのデプロイ

ここまでで、ASP.NET コンパイル ツールで、更新可能なユーザー インターフェイス オプションと更新不可能なユーザー インターフェイス オプションの両方を使用して Web サイトをプリコンパイルする方法について説明しました。 しかしこの例では、運用環境ではなく、ローカル フォルダーに Web サイトをプリコンパイルしました。 幸いなことに、プリコンパイル済み Web サイトのデプロイは簡単で、Visual Studio またはスタンドアロン FTP クライアントなどの他のファイル コピー メカニズムを使用して実行できます。

[Web サイトの発行] ダイアログ ボックス (最初の 図 1 に示しました) には、プリコンパイル済みの Web サイト ファイルのコピー先を示すターゲットの場所オプションがあります。 この場所には、リモート Web サーバーまたは FTP サーバーを指定できます。 このテキスト ボックスにリモート サーバーを入力すると、1 つの手順で指定したサーバーに Web サイトがプリコンパイルされ、デプロイされます。 または、Web サイトをローカル フォルダーにプリコンパイルしてから、FTP またはその他の方法で、そのフォルダーの内容を運用環境に手動でコピーすることもできます。

Visual Studio の [Web サイトの発行] ダイアログ ボックスを使用してプリコンパイル済み Web サイトを自動的にデプロイする方法は、開発環境と運用環境の構成に違いがないようなシンプルなサイトに役立ちます。 ただし、「開発と運用の間の一般的な構成の違い」チュートリアルで説明したような違いが存在することは珍しくありません。 たとえば、ブック レビュー Web アプリケーションは、開発環境とは異なる運用環境のデータベースを使用します。 Visual Studio が Web サイトをリモート サーバーに発行すると、開発環境の構成ファイル情報が無条件でコピーされます。

開発環境と運用環境の構成が異なるサイトの場合は、サイトをローカル ディレクトリにプリコンパイルし、運用固有の構成ファイルをコピーしてから、プリコンパイル済み出力のコンテンツを運用環境にコピーすることをお勧めします。

開発環境から運用環境へのファイルのコピーの詳細については、FTP クライアントを使用したサイトのデプロイや Visual Studio を使用した Web サイトのデプロイに関するチュートリアルを参照してください。

まとめ

ASP.NET では、自動と明示的の 2 つのコンパイル モードがサポートされています。 前のチュートリアルで説明したように、Web アプリケーション プロジェクト (WAP) では明示的なコンパイルが使用され、Web サイト プロジェクト (WSP) では自動コンパイルが既定で使用されます。 ただし、ASP.NET コンパイル ツールを使用して、デプロイする前に WSP を明示的にコンパイルすることもできます。

このチュートリアルでは、コンパイル ツールのデプロイ サポートのプリコンパイルに焦点を合わせて説明しました。 デプロイ用にプリコンパイルする場合、コンパイル ツールはターゲットの場所フォルダーを作成し、指定された Web アプリケーションのソース コードをコンパイルし、これらのコンパイル済みアセンブリとコンテンツ ファイルをターゲットの場所フォルダーにコピーします。 コンパイル ツールは、更新可能または更新不可能なユーザー インターフェイスを作成するように構成できます。 更新不可能なユーザー インターフェイス オプションを使用してプリコンパイルすると、コンテンツ ファイル内の宣言型マークアップが削除されます。 簡単に言うと、プリコンパイルを使用すると、ソース コード ファイルを含めずに、必要に応じて宣言型マークアップを削除して、Web サイト プロジェクト ベースのアプリケーションをデプロイできます。

プログラミングに満足!

もっと読む

この記事で説明したトピックの詳細については、次のリソースを参照してください。

• ASP.NET Web サイトのプリコンパイル
• ASP.NET 2.0 でのコードビハインドとコンパイル
• ASP.NET でのプリコンパイル
• ASP.NET でのプリコンパイル済みサイト オプション