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

[アーティクル]
07/13/2023

Visual Studio には、開発者 ASP.NET Web アプリケーションプロジェクト (WAP) と Web サイトプロジェクト (WSP) の 2 種類のプロジェクトが用意されています。 2 つのプロジェクトの種類の主な違いの 1 つは、展開前に WAP でコードを明示的にコンパイルする必要があるのに対し、WSP 内のコードは Web サーバー上で自動的にコンパイルできることです。ただし、展開前に 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 サーバー上でオンデマンドでコンパイルされます。

Note

プロジェクトモデルの違い、明示的コンパイルと自動コンパイル、およびコンパイルモデルの配置への影響の詳細については、「 配置する必要があるファイルの決定 」チュートリアルの「明示的コンパイルと自動コンパイル」セクションに戻ってください。

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

最初にアクセスしたときにページを自動的にコンパイルする必要があるため、展開後に ASP.NET ページが初めて要求されると、短いが顕著な遅延が発生する可能性があります。
自動コンパイルでは、宣言型マークアップとソースコードの両方が Web サーバーに存在する必要があります。 Web アプリケーションを Web サーバーにインストールする顧客に販売する予定の場合、これは魅力的でないオプションになる可能性があります。

上記の 2 つの欠点のいずれかが案件ブレーカーの場合は、WAP モデルに切り替えるか、展開する前に WSP を プリコンパイル できます。このチュートリアルでは、ホストされている Web サイトに最適なプリコンパイルオプションについて説明し、プリコンパイルプロセスとプリコンパイル済み Web サイトのデプロイについて説明します。

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

使用可能なプリコンパイルオプションを見る前に、最初に、ASP.NET ページが作成または最後に更新されてから初めて要求されたときに発生するコードの生成とコンパイルについて説明します。ご存知のように、ASP.NET ページは、ファイル内 .aspx の宣言型マークアップと、通常は別の分離コードクラスファイル (.aspx.vb) 内のソースコード部分の 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に保存されますが、このフォルダーの場所はの Web.config要素を<pages>使用してカスタマイズできます。アセンブリはディスクに保存されるため、同じページに対する後続の要求で再コンパイルする必要はありません。

Note

ご期待のとおり、サーバーがページのコードをコンパイルし、結果のアセンブリをディスクに保存するのに少し時間がかかるため、自動コンパイルを使用するサイトで初めて (または変更されてから初めて) ページを要求すると、若干の遅延が発生します。

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

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

私はWAPとWSPの間で異なる低レベルの実装の詳細をあまり追跡したくないが、簡単に言えば、ランタイムは保護されたメンバーとメソッドとしてさまざまなWebコントロールを含むクラスファイルを自動的に生成する。この生成されたファイルは、対応する分離コード クラスの部分クラス として実装されます。 (部分クラスを使用すると、1 つのクラスの内容を複数のファイルに分散できます)。そのため、分離コードクラスは、作成するファイルと、ランタイムによって作成された自動生成されたクラスの 2 つの場所 .aspx.vb で定義されます。この自動生成されたクラスは、フォルダーに %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。コマンドラインから使用することも、[ビルド] メニューの [Web サイトの発行] オプションを使用して Visual Studio 内から起動することもできます。

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

Note

インプレースプリコンパイルの詳細については、「方法: ASP.NET Web サイトをプリコンパイルする方法」と「ASP.NET 2.0 でのプリコンパイル」をチェック。

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

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

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

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

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

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

Note

[ビルド] メニューの [Web サイトの発行] オプションは、Visual Web Developer では使用できません。 Visual Web Developer を使用している場合は、「コマンドラインからのプリコンパイル」セクションで説明されている ASP.NET コンパイルツールのコマンドラインバージョンを使用する必要があります。

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

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

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

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

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

Note

[Web サイトの発行] ダイアログボックスの [固定の名前付けと単一ページアセンブリを使用] チェックボックスをオンにすることで、ASP.NET ページ、ユーザーコントロール、またはマスターページごとに 1 つのアセンブリを作成するようにコンパイルツールに指示できます。各 ASP.NET ページを独自のアセンブリにコンパイルすると、デプロイをよりきめ細かく制御できます。たとえば、1 つの ASP.NET Web ページを更新し、その変更を展開する必要がある場合は、そのページの .aspx ファイルと関連するアセンブリのみを運用環境に展開する必要があります。詳細については、「方法: ASP.NET コンパイルツールを使用して固定名を生成する」を参照してください。

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

最後に、Visual Studio または任意のテキストエディターを .aspx 使用して、ターゲットの場所にあるいずれかのファイルを開きます。更新可能なユーザーインターフェイスを使用して配置をプリコンパイルする場合、ターゲットの場所ディレクトリ内の 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 を使用する場合は、Visual Web Developer の [ビルド] メニューに [Web サイトの発行] オプションが含まれていないので、コマンドラインからコンパイラツールを実行する必要があります。

コマンドラインからコンパイラツールを使用するには、まずコマンドラインにドロップし、 %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解決されます。ブックレビューサイトは私のウェブホスティング会社のルートディレクトリに置かれているので、私はスイッチ -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 サイトを自動的に展開すると、開発環境と運用環境の間に構成の違いがない単純なサイトに役立ちます。ただし、「 開発と運用の間の一般的な構成の違い 」チュートリアルで説明されているように、このような違いが存在することは珍しくありません。たとえば、Book Reviews Web アプリケーションでは、開発環境とは異なるデータベースが運用環境で使用されます。 Visual Studio が Web サイトをリモートサーバーに発行すると、開発環境で構成ファイル情報が盲目的にコピーされます。

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

開発環境から運用環境へのファイルのコピーに関する更新については、「 FTP クライアントを使用した Web サイトの展開 」および 「Visual Studio を使用した Web サイトの展開」 のチュートリアルを参照してください。

まとめ

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

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

幸せなプログラミング!

もっと読む

このチュートリアルで説明するトピックの詳細については、次のリソースを参照してください。

Previous Next /previous-versions/aspnet/bb398860(v=vs.100)

Share via

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

はじめに

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