ネタもと：Insider.NET VS2005 ASP.NET での Debug/Release 構成について

情報もと：K. Scott Allen Debug and Release Builds in ASP.NET 2.0

LogoVista X Pro 3.0 R07 による、機械翻訳。

ASP.NET 1.1から2.0を移行するときするべき調整の1つがどのように debug とリリースビルドを生産するべきかです。

1.1

1.1で我々はビルド -> 構成マネージャ メニューオプションを持っていました。このコマンドは利用可能なビルドから構成を選択させるためにダイアログ・ボックスを始動しました。ビジュアル・スタジオはデフォルトでデバッグ (Debug) とリリース構成を提供しました。構成マネージャで選択された構成はビジュアル・スタジオ (Visual Studio) にどのようにコード・ビハインドファイルをコンパイルするべきか教えるでしょう。構成がデバッギングシンボルを求めた場合は、成功したコンパイルが、デバッギングシンボルファイル（.pdb ファイル）が現われるという状態で、binディレクトリで一つのアセンブリ（DLL）を作り出すでしょう。

いつか後に、アプリケーションは Web のリクエストを受けて、そして実行し始めるでしょう。この時点で、 ASP.NET ランタイムは Web フォームのコードを生成するでしょう。そしてそれから、ユーザーコントロールがアプリケーションで、生成されたコードをコンパイルします。 ランタイムにおいてのコンパイルは web.config ファイルの compile セクションにおける debug 設定をそれがコンパイルするべきであるかどうかが最適化したコード、あるいは debug コードを決定するために使うでしょう。ASP.NET は一時的な ASP.NET Files ディレクトリの下に結果を置くでしょう。1.1で本当のプロダクトビルドを作り出すために、VisualStudio.NET 2003のリリース構成を選択して、そしてweb.config ファイルで debug="false" と設定することは重要です。

2.0

ここに2.0で折り合うべき最も重要なコンセプトがあります： Web アプリケーションをコンパイルすることについて、ビジュアル・スタジオ2005は何も知りません。1.1で VS はコード・ビハインドを構築しました。そして ASP.NET は Web フォームを構築しました。2.0 の Visual Studio 2005は ASP.NET プラットホームにすべてのコンパイル応答性を委任します。

それを記憶して、話をするべき2つのシナリオがあります：ウェブサイト配置プロジェクトなしで Web アプリケーションを構築することと、ウェブサイト配置プロジェクトで Web アプリケーションを構築すること。

"配置プロジェクトなし"から始めましょう。

Visual Studio に Web プロジェクトを構築するように依頼するとき、何も起きるように思われません。内部に DLL ファイルで bin ディレクトリを持っている気分が休まる感じを得ません。 これは、Visual Studio ではなく、 ASP.NET がビルドを実行するからです。ASP.NET は、 C# ファイルと VB ファイルコードファイルを含めて、すべてを構築します。 ASP.NET はすべての結果として生じているアセンブリを一時的な ASP.NET ファイルディレクトリの下のフォルダーに置きます。ディレクトリでせん索すると、ビルドの結果を見るでしょう。

ASP.NET がコンパイルのすべてをするので、 web.config ファイルのコンパイルのセクションでの debug 設定は debug あるいは release モードをコントロールします。 debug="true" とによるコンパイルとそれぞれのアセンブリと並んで .pdb ファイルのデバッギングシンボルファイルを見いだすでしょう。

この新しいコンパイルモデルはウェブサイトの構成マネージャ を時代遅れにします。Visual Studio 2005のウェブサイト「プロジェクト」に現われている唯一の選択肢は Debug 構成です。 くよくよしないでください － それは何も意味しません。 web.config ファイルファイルは今群れを決定します。

配置される準備ができているとき、ウェブサイトを発表することができます。 Publish コマンド（ビルド -> ウェブサイトの配置）は Web アプリケーションをプリコンパイルして、選択したディレクトリに結果として配置するでしょう。 IIS あるいは FTP の場所に同じく配置することができます。 Publish コマンドを選択するとき、配置先と厳密な名前をつける、固定された名前を付けるなどのオプションを選ぶダイアログ・ボックスが表示されるでしょう。 これらの選択肢は（もっと多くの詳細については私の記事を見てください）コマンドライン aspnet_compiler ツールのオプションにマップします。 aspnet_compiler ツールはデバッギングシンボルを作り出すために同じくオプションを供給します。しかしこの選択肢は Publish ダイアログから利用可能ではありません。 Publish は常にデバッギングシンボルなしでリリースビルドをプリコンパイルするでしょう。

ノート： Publish コマンドは、更新可能なウェブサイトにプリコンパイルして、そして次に（ダイナミックなコンパイルをもたらす）決まった場所にあるウェブサイトを更新する場合は、ダイナミックなコンパイルが作り出すであろう人たちがコードとデバッグシンボルファイル (.pdb) ファイルをデバッグするとしても、 Publish コマンドが常にコンパイルする web.config. で debug 設定を「リリース」と交換しません。

新しいウェブサイト配置（WSD）プロジェクトは少し上記のシナリオを変えます。 WSD は Visual Studio 2005 の構成管理テーブルにリリースと Debug 構成を加えます。 これは Visual Studio がどのようにウェブサイトをコンパイルするべきか知っていることを意味しません。 その代わりに、 Visual Studio はどのように WSD によって提供された MSBuild ファイルをデバッグ (Debug) とリリースビルドを求めるために使うべきか知っています。 Visual Studio で構成マネージャ から今デバッグ (Debug) あるいはリリースを選択することができます。 ビルドのリクエストは究極的に Publish コマンドによって上に記述されて、そして使われたのと同じ aspnet_compiler ツールに到達します。

Publish コマンドと異なり、 WSD リリースビルドが falseで web.config ファイルの debug 設定をそうするように変えるでしょう。 リリースビルドをリリースディレクトリに置くことに、 WSD は同じく義務を怠ります、そして Web フォーム以外に .NET を使っている誰にでもよく知られている Debug ディレクトリでビルドをデバッグしてください。 WSD は驚嘆に値するツールです、そして私は意志が（結局は）ここでもっと多くの詳細でカバーされていると確信しています。

∥結論として、ビルドを使うことをデバッグして、そして放ってくださいとコントロールする∥ － Publish コマンドあるいはウェブサイト配置ツールでウェブサイトを前もってコンパイルしていないなら、 web.config ファイルでコンパイルのセクションの属性をデバッグする∥. WSD はデバッグ (Debug) あるいはリリースビルドを選択させるでしょう、サイトを前もって編集して、そして適切に web.config ファイルを修正します。