ASP.NET の動的コンパイルの概要
更新 : 2007 年 11 月
Web アプリケーションから要求に対してサービスを提供するには、ASP.NET で Web アプリケーションのコードを解析してから、1 つまたは複数のアセンブリにコンパイルする必要があります。コードはコンパイルされると、言語にも CPU にも依存しない Microsoft Intermediate Language (MSIL) と呼ばれる表現に変換されます。実行時、MSIL は .NET Framework のコンテキストで実行します。.NET Framework 上で、MSIL はアプリケーションを実行するコンピュータ上のプロセッサに対する CPU 固有の命令に変換されます。
最初の要求でのコンパイル
既定では、ユーザーが Web サイトの ASP.NET ページ (.aspx ファイル) などのリソースを最初に要求したときに、ASP.NET Web ページとコード ファイルが動的にコンパイルされます。ページとコード ファイルが初めてコンパイルされた後、コンパイルされたリソースはキャッシュされるので、同じページに対するその後の要求が非常に効率良く処理されます。
ASP.NET は、ASP.NET ページ (.aspx ファイル)、ASP.NET Web サービス (.asmx ファイル)、ASP.NET HTTP ハンドラ (.ashx ファイル)、ASP.NET アプリケーション ファイル (Global.asax) だけでなく、ソース コードやクラス ファイルなどのファイルについても、動的コンパイルをサポートしています。ASP.NET ファイルの種類の詳細については、「Web サイトのファイルの種類」を参照してください。ASP.NET コンパイル プロセスの詳細については、「IIS 5.0 および 6.0 における ASP.NET アプリケーションのライフ サイクルの概要」の「コンパイルのライフ サイクル」のセクションを参照してください。
変更時の再コンパイル
動的にコンパイルしたファイルが変更されると、そのファイルのキャッシュされているコンパイル済みアセンブリが自動的に無効になり、すべての関連リソースの再コンパイルがトリガされます。次にコードに対する要求が生成されると、ASP.NET ではコードが変更されたと認識され、Web アプリケーションの関連リソースが再コンパイルされます。このシステムによって、コンパイル処理のオーバーヘッドを最小限に抑えて、アプリケーションを迅速に開発できます (リソースの変更内容によって、結果は単一ページの再コンパイルの場合から Web サイト全体の再コンパイルの場合まであります)。
コンパイルの依存関係
アプリケーションに対して最初の要求が行われると、ASP.NET は指定された順番でファイルをコンパイルします。最初にコンパイルされる項目はトップレベルの項目と呼ばれます。最初の要求の後、トップレベルの項目は依存関係が変更された場合のみ再コンパイルされます。
トップレベルの項目には、App_GlobalResources フォルダ、App_WebResources フォルダ、プロファイル プロパティ、App_Code フォルダ、および Global.asax ファイルがあります。トップレベルの項目がコンパイルされた後、その他の項目がコンパイルされます。その他の項目には、App_LocalResources フォルダ、個々の ASP.NET ページ (.aspx ファイル)、ASP.NET ユーザー コントロール (.ascx ファイル)、ASP.NET HTTP ハンドラ (.ashx ファイル)、ASP.NET HTTP モジュール (.asmx ファイル) だけでなく、テーマ、マスタ ページなどのソース ファイルも含まれます。
詳細については、「ASP.NET Web サイトのレイアウト」と「IIS 5.0 および 6.0 における ASP.NET アプリケーションのライフ サイクルの概要」の「コンパイルのライフ サイクル」を参照してください。
コンパイルの出力
コードをコンパイルすると、結果のアセンブリがサーバーのフォルダにキャッシュされます。コードのコンパイルと実行が正常に行われるには、このフォルダに適切なアクセス許可が必要です。コンパイル フォルダの場所と、コードのコンパイルと実行を行うアクセス許可の両方を設定できます。
コンパイル フォルダの場所
既定で、Web アプリケーションをコンパイルすると、コンパイルされたコードは Temporary ASP.NET Files フォルダに配置されます。このフォルダは、.NET Framework をインストールした場所のサブディレクトリです。通常は、次の場所になります。
%SystemRoot%\Microsoft.NET\Framework\versionNumber\Temporary ASP.NET Files
コンパイル フォルダに必要なアクセス許可
.NET のインストール プロセスによって、Temporary ASP.NET Files フォルダが作成され、アクセス許可が ASP.NET のローカル ユーザー アカウントに割り当てられます。このアカウントには、コンパイル済みコードにアクセスするときに必要な信頼性の高いアクセス許可があります。構成とアカウント設定を変更する場合、使用するアカウントに、Temporary ASP.NET Files フォルダに対する信頼性の高いアクセス許可があることを確認します。詳細については、「方法 : ユーザー アカウントでワーカー プロセスを実行する」を参照してください。
コンパイル フォルダの設定可能性
ASP.NET は、各アプリケーションの Temporary ASP.NET File フォルダ以下に個々のサブフォルダを作成します。ルート位置は、構成ファイルの compilation セクションの tempDirectory 属性を使用して構成できます。このオプション属性で、コンパイル時に一時的なファイル ストレージに使用されるディレクトリを指定できます。既定値は、空の文字列 ("") です。空の文字列で、現在のプロセスに必須のアクセス許可がある場合、ファイルは次のディレクトリに格納されます。
%FrameworkInstallLocation%\Temporary ASP.NET Files
詳細については、「compilation 要素 (ASP.NET 設定スキーマ)」と CompilationSection の TempDirectory プロパティを参照してください。
複数言語のサポート
ASP.NET 2.0 では、同じ Web アプリケーションで複数のプログラミング言語をサポートしています。App_Code ディレクトリには、C# や Visual Basic など各言語のサブフォルダを指定できます。各サブフォルダに個別のアセンブリが作成されます。詳細については、「ASP.NET Web サイト内の共有コード フォルダ」および「チュートリアル : 複数のプログラミング言語を使用した Web サイトの開発」を参照してください。
動的コンパイルの利点と欠点
ASP.NET の動的コンパイルによって、Web アプリケーションを配置する前に、コードを明示的にコンパイルしなくても、ソース コードを変更できます。ソース ファイルを変更すると、自動的にファイルが再コンパイルされ、すべてのリンク済みリソースが更新されます。<processModel> セクションを変更しない限り、変更を適用するために IIS サーバーを再起動する必要はありません。さらに、コンパイル時に呼び出される新しいファイルの種類に対してカスタム ビルド プロバイダを作成することで、ASP.NET のビルド システムを拡張できます。ASP.NET ビルド システムの動的コンパイルの利点は、古い ASP.NET のアプリケーション構造と種類に下位互換性があることです。
動的コンパイルでは提供されない機能もあります。動的コンパイルの場合、ユーザーは最初の応答が遅いと感じる可能性があります。これは、ページ ファイルとコード ファイルは最初に要求されるときにコンパイルされるためです。これは、更新頻度の高い大規模なサイトで、特に問題になる可能性があります。動的コンパイルには、ユーザーがサイトにアクセスする前に、コンパイル時のバグを特定する手段がありません。また、動的コンパイルには、ソース コードを含めずに運用サーバーに配置できるサイトのコンパイル済みバージョンを作成する機能もありません。このような問題が Web アプリケーションで問題になる場合は、Web サイトをプリコンパイルできます。詳細については、「ASP.NET のプリコンパイルの概要」を参照してください。
参照
処理手順
方法 : 共有サーバー上の ASP.NET アプリケーションを保護する