構成とインストルメンテーション
作成者: Microsoft
Note
この記事が作成されてから、ASP.NET メンバーシップ プロバイダーは ASP.NET Identity に置き換えられました。 アプリを更新し、この記事の作成時点で紹介したメンバーシップ プロバイダーではなく、 ASP.NET Identity プラットフォームを使用することを強く推奨します。 ASP.NET メンバーシップ システムと比較すると、ASP.NET ID には以下を含む多くの利点があります。
- パフォーマンスの向上
- 向上した拡張性とテストの容易性
- OAuth、OpenID Connect、2 要素認証のサポート
- クレームベースの ID のサポート
- 向上した ASP.Net Core との相互運用性
ASP.NET 2.0 では、構成とインストルメンテーションに大きな変更があります。 新しい ASP.NET 構成 API を使用すると、構成の変更をプログラムで行うことができます。 さらに、多くの新しい構成設定が存在することで、新しい構成とインストルメンテーションが可能になります。
ASP.NET 2.0 では、構成とインストルメンテーションに大きな変更があります。 新しい ASP.NET 構成 API を使用すると、構成の変更をプログラムで行うことができます。 さらに、多くの新しい構成設定が存在することで、新しい構成とインストルメンテーションが可能になります。
このモジュールでは、ASP.NET 構成ファイルの読み取りと書き込みに関連する ASP.NET 構成 API について説明し、ASP.NET インストルメンテーションについても説明します。 また、ASP.NET トレースで使用できる新機能についても説明します。
ASP.NET 構成 API
ASP.NET 構成 API を使用すると、単一のプログラミング インターフェイスを使用して、アプリケーション構成データを開発、展開、管理できます。 構成 API を使用すると、構成ファイル内の XML を直接編集することなく、完全な ASP.NET 構成をプログラムで開発および変更できます。 さらに、開発するコンソール アプリケーションとスクリプト、Web ベースの管理ツール、Microsoft 管理コンソール (MMC) スナップインで構成 API を使用できます。
次の 2 つの構成管理ツールは、構成 API を使用しており、.NET Framework バージョン 2.0 に含まれています。
- ASP.NET MMC スナップインでは、構成 API を使用して管理タスクを簡略化し、構成階層の全レベルのローカル構成データを統合して表示できるようにします。
- Web サイト管理ツールを使用すると、ホストされているサイトを含むローカルおよびリモート アプリケーションの構成設定を管理できます。
ASP.NET 構成 API は、Web サイトとアプリケーションをプログラムで構成するために使用できる一連の ASP.NET 管理オブジェクトで構成されています。 管理オブジェクトは、.NET Framework クラス ライブラリとして実装されます。 構成 API プログラミング モデルでは、コンパイル時にデータ型を適用して、コードの一貫性と信頼性を確保できるようにします。 アプリケーション構成の管理を容易化するために、構成 API を使用すると、構成階層内の全ポイントからマージしたデータをさまざまな構成ファイルの個別のコレクションとして表示するのではなく、1 つのコレクションとして表示できます。 さらに、構成 API を使用すると、構成ファイル内の XML を直接編集することなく、アプリケーション構成全体を操作できます。 最後に、この API では、Web サイト管理ツールなどの管理ツールをサポートして、構成タスクを簡略化します。 構成 API は、コンピューター上で構成ファイルの作成をサポートし、複数のコンピューター間で構成スクリプトを実行して、展開を簡略化します。
Note
構成 API は、IIS アプリケーションの作成をサポートしていません。
ローカルおよびリモート構成設定の操作
構成オブジェクトは、コンピューターなどの特定の物理エンティティ、またはアプリケーションや Web サイトなどの論理エンティティに適用される構成設定をマージしたビューを表します。 指定した論理エンティティは、ローカル コンピューターまたはリモート サーバーに保存できます。 指定したエンティティの構成ファイルが存在しない場合、構成オブジェクトは Machine.config ファイルで定義されたデフォルトの構成設定を表します。
構成オブジェクトを取得するには、次のクラスからオープンになっている構成メソッドのいずれかを使用します。
- エンティティがクライアント アプリケーションの場合は、ConfigurationManager クラス。
- エンティティが Web アプリケーションの場合は、WebConfigurationManager クラス。
これらのメソッドは構成オブジェクトを返します。これにより、基になる構成ファイルを処理するために必要なメソッドとプロパティが提供されます。 これらのファイルには、読み取りまたは書き込みのためにアクセスできます。
読み取り中
構成情報の読み取りには、GetSection または GetSectionGroup メソッドを使用します。 読み取りを行うユーザーまたはプロセスには、階層内のすべての構成ファイルに対する読み取りアクセス許可が必要です。
Note
パス パラメーターを受け取る静的な GetSection メソッドを使用する場合、パス パラメーターでコードが実行されているアプリケーションを参照する必要があります。 そのようにしない場合、パラメーターは無視され、現在実行中のアプリケーションの構成情報が返されます。
書き込み
構成情報を書き込むには、いずれかの Save メソッドを使用します。 書き込むユーザーまたはプロセスには、現在の構成階層レベルの構成ファイルとディレクトリに対する書き込みアクセス許可と、階層内のすべての構成ファイルに対する読み取りアクセス許可が必要です。
指定したエンティティの継承された構成設定を表す構成ファイルを生成するには、次のいずれかの保存構成メソッドを使用します。
- 新しい構成ファイルを作成する Save メソッド。
- 別の場所に新しい構成ファイルを生成する SaveAs メソッド。
構成クラスと名前空間
多くの構成クラスとメソッドは互いに類似しています。 次の表では、最もよく使用される構成クラスと名前空間について説明します。
| 構成クラスまたは名前空間 | 説明 |
|---|---|
| System.Configuration 名前空間 | すべての .NET Framework アプリケーションのメイン構成クラスが含まれています。 セクション ハンドラー クラスは、GetSection や GetSectionGroup などのメソッドからセクションの構成データを取得するために使用されます。 これら 2 つのメソッドは非静的です。 |
| System.Configuration.Configuration クラス | コンピューター、アプリケーション、Web ディレクトリ、その他のリソースの一連の構成データを表します。 このクラスには、GetSection や GetSectionGroup など、構成設定の更新とセクションおよびセクション グループへの参照の取得に役立つメソッドが含まれます。 このクラスは、WebConfigurationManager および ConfigurationManager クラスのメソッドなど、デザイン時の構成データを取得するメソッドの戻り値の型として使用されます。 |
| System.Web.Configuration 名前空間 | ASP.NET 構成設定で定義した ASP.NET 構成セクションのセクション ハンドラー クラスが含まれています。 セクション ハンドラー クラスは、GetSection や GetSectionGroup などのメソッドからセクションの構成データを取得するために使用されます。 |
| System.Web.Configuration.WebConfigurationManager クラス | 実行時およびデザイン時の構成設定への参照を取得するために役立つメソッドとして使用できます。 これらのメソッドでは、戻り値の型として System.Configuration.Configuration クラスを使用します。 このクラスの静的な GetSection メソッドまたは System.Configuration.ConfigurationManager クラスの非静的 GetSection メソッドは相互に置き換えて使用できます。 Web アプリケーション構成の場合は、System.Configuration.ConfigurationManager クラスの代わりに System.Web.Configuration.WebConfigurationManager クラスが推奨されます。 |
| System.Configuration.Provider 名前空間 | 構成プロバイダーをカスタマイズして拡張できます。 これは、構成システム内のすべてのプロバイダー クラスの基底クラスです。 |
| System.Web.Management 名前空間 | Web アプリケーションの正常性を管理および監視するためのクラスおよびインターフェイスが含まれています。 厳密に言うと、この名前空間は構成 API の一部とは見なされません。 たとえば、トレースとイベントの発生は、この名前空間のクラスによって実現されます。 |
| System.Management.Instrumentation 名前空間 | アプリケーションのインストルメンテーションで Windows Management Instrumentation (WMI) を介して潜在的なコンシューマーに管理情報とイベントを公開するために必要なクラスです。 ASP.NET の稼働状況の監視では、WMI を使用してイベントを配信します。 厳密に言うと、この名前空間は構成 API の一部とは見なされません。 |
ASP.NET 構成ファイルからの読み取り
WebConfigurationManager クラスは、ASP.NET 構成ファイルからの読み取り用のコア クラスです。 基本的に、ASP.NET 構成ファイルの読み取りには、3 つの手順があります。
- OpenWebConfiguration メソッドを使用して構成オブジェクトを取得する。
- 構成ファイル内の目的のセクションへの参照を取得する。
- 構成ファイルから必要な情報を読み取る。
構成オブジェクトは、特定の構成ファイルを表していません。 代わりに、コンピューター、アプリケーション、Web サイトの構成のマージされたビューを表します。 次のコード サンプルでは、ProductInfo という Web アプリケーションの構成を表す構成オブジェクトのインスタンスを作成します。
Configuration config = WebConfigurationManager.OpenWebConfiguration("/ProductInfo);
Note
/ProductInfo パスが存在しない場合、上記のコードは machine.config ファイルで指定されているデフォルトの構成を返します。
構成オブジェクトを取得したら、GetSection または GetSectionGroup メソッドを使用して、構成設定の詳細を掘り下げることができます。 次の例では、上記の ProductInfo アプリケーションの権限借用設定への参照を取得します。
Configuration config =
WebConfigurationManager.OpenWebConfiguration("/ProductInfo);
IdentitySection section =
(IdentitySection)config.GetSection("system.web/identity");
ASP.NET 構成ファイルへの書き込み
構成ファイルからの読み取りと同様に、WebConfigurationManager クラスは、ASP.NET 構成ファイルに書き込むためのコアとなります。 また、ASP.NET 構成ファイルへの書き込みにも、3 つの手順があります。
- OpenWebConfiguration メソッドを使用して構成オブジェクトを取得する。
- 構成ファイル内の目的のセクションへの参照を取得する。
- Save メソッドまたは SaveAs メソッドを使用して、構成ファイルから必要な情報を書き込む。
次のコードは、<compilation> 要素の debug 属性を false に変更します。
System.Configuration.Configuration updateWebConfig =
System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("/webApp");
System.Web.Configuration.CompilationSection compilation =
updateWebConfig.GetSection("system.web/compilation")
as System.Web.Configuration.CompilationSection;
compilation.Debug = false;
if (!compilation.SectionInformation.IsLocked) {
updateWebConfig.Save();
Response.Write("Save Success!");
} else {
Response.Write("Save Failed!");
}
このコードを実行すると、<compilation> 要素の debug 属性が webApp アプリケーションの web.config ファイルに対して false に設定されます。
System.Web.Management 名前空間
System.Web.Management 名前空間には、ASP.NET アプリケーションの正常性を管理および監視するためのクラスとインターフェイスが用意されています。
ログ記録を行うには、イベントをプロバイダーに関連付けるルールを定義します。 このルールでは、プロバイダーに送信するイベントの種類を定義します。 次の基底イベントをログに記録できます。
| WebBaseEvent | あらゆるイベント用の基底イベント クラスです。 イベント コード、イベント詳細コード、イベントが発生した日時、シーケンス番号、イベント メッセージ、イベントの詳細など、すべてのイベントに必要なプロパティが含まれます。 |
|---|---|
| WebManagementEvent | アプリケーションの有効期間、要求、エラー、監査イベントといった管理イベントの基底イベント クラスです。 |
| WebHeartbeatEvent | 有用なランタイム状態情報をキャプチャするために、アプリケーションによって一定の間隔で生成されるイベントです。 |
| WebAuditEvent | 認可エラー、解読エラーなどの条件をマークするために使用するセキュリティ監査イベントの基底クラスです。 |
| WebRequestEvent | すべての情報要求イベント用の基底クラスです。 |
| WebBaseErrorEvent | エラー条件を示すあらゆるイベント用の基底クラスです。 |
利用可能な種類のプロバイダーを使用して、イベント ビューアー、SQL Server、Windows Management Instrumentation (WMI)、メールにイベント出力を送信できます。 事前構成済みのプロバイダーとイベント マッピングにより、イベント出力をログに記録するために必要な作業量が削減されます。
ASP.NET 2.0 では、イベント ログ プロバイダーをすぐに使用して、アプリケーション ドメインの開始と停止に基づいてイベントをログに記録し、ハンドルされない例外もログに記録します。 これは、いくつかの基本的なシナリオをカバーするのに役立ちます。 たとえば、アプリケーションで例外をスローしたものの、ユーザーがエラーを保存せず、再現できないとします。 デフォルトのイベント ログ ルールを使用すると、例外とスタック情報を収集して、発生したエラーの種類をより良く把握できます。 アプリケーションがセッション状態を失っている場合は、別の例が適用されます。 その場合は、イベント ログを見て、アプリケーション ドメインがリサイクルされているかどうかと、アプリケーション ドメインが最初に停止した理由を確認できます。
また、稼働状況の監視システムは拡張可能です。 たとえば、カスタム Web イベントを定義し、アプリケーション内で起動してから、ご利用のメールなどのプロバイダーにイベント情報を送信するルールを定義できます。 これにより、インストルメンテーションを稼働状況の監視プロバイダーに簡単に関連付けられます。 別の例として、命令が処理されるたびにイベントを発生させて、各イベントを SQL Server データベースに送信するルールを設定できます。 また、ユーザーが複数回連続してログオンできない場合にイベントを発生させて、メール ベースのプロバイダーを使用するようにイベントを設定することもできます。
デフォルトのプロバイダーとイベントの構成は、グローバル Web.config ファイルに保存されます。 グローバル Web.config ファイルには、ASP.NET 1x の Machine.config ファイルに保存されたすべての Web ベースの設定が保存されます。 グローバル Web.config ファイルは、次のディレクトリにあります。
%windir%\Microsoft.Net\Framework\v2.0.*\config\Web.config
グローバル Web.config ファイルの <healthMonitoring> セクションには、デフォルトの構成設定が用意されています。 アプリケーションの Web.config ファイルに <healthMonitoring> セクションを実装すると、これらの設定をオーバーライドするか、独自の設定を構成できます。
グローバル Web.config ファイルの <healthMonitoring> セクションには、次の項目が含まれています。
| providers | イベント ビューアー、WMI、SQL Server 用に設定されたプロバイダーが含まれています。 |
|---|---|
| eventMappings | さまざまな WebBase クラスのマッピングが含まれています。 独自のイベント クラスを生成する場合は、このリストを拡張できます。 独自のイベント クラスを生成すると、情報の送信先となるプロバイダーに対しての細分性がさらに細かくなります。 たとえば、独自のカスタム イベントをメールに送信する一方で、ハンドルされない例外を SQL Server に送信するように構成できます。 |
| rules | eventMappings をプロバイダーにリンクします。 |
| buffering | SQL Server およびメール プロバイダーで使用して、プロバイダーにイベントをフラッシュする頻度を決定します。 |
グローバル Web.config ファイルからのコード例を以下に示します。
<healthMonitoring>
<!-- Event Log Provider being added. -->
<providers>
<add name="EventLogProvider"
type="System.Web.Management.EventLogWebEventProvider,
System.Web,Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
<!-- Event mapping provides a friendly name to the
events based on the WebBaseErrorEvent class. -->
<eventMappings>
<add name="All Errors"
type="System.Web.Management.WebBaseErrorEvent,
System.Web,Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"
startEventCode="0" endEventCode="2147483647" />
</eventMappings>
<!-- Rule tying the "All Errors" event mapping to the EventLog Provider. -->
<rules>
<add name="All Errors Default" eventName="All Errors"
provider="EventLogProvider"
profile="Default" minInstances="1"
maxLimit="Infinite" minInterval="00:01:00" custom="" />
</rules>
</healthMonitoring>
イベントをイベント ビューアーに保存する方法
前述のように、イベント ビューアーでイベントをログに記録するためのプロバイダーは、グローバル Web.config ファイルで構成されます。 既定では、WebBaseErrorEvent と WebFailureAuditEvent に基づくすべてのイベントがログに記録されます。 追加のルールを追加すると、イベント ログに追加情報を記録できます。 たとえば、すべてのイベント (つまり、WebBaseEvent に基づくすべてのイベント) をログに記録する場合は、Web.config ファイルに次のルールを追加できます。
<healthMonitoring>
<rules>
<add name="All Events" eventName="All Events"
provider="EventLogProvider" profile="Critical" />
</rules>
</healthMonitoring>
このルールでは、All Events イベント マップをイベント ログ プロバイダーにリンクします。 eventMapping とプロバイダーの両方がグローバル Web.config ファイルに含まれています。
SQL Server にイベントを保存する方法
このメソッドでは、Aspnet_regsql.exe ツールによって生成される ASPNETDB データベースを使用します。 デフォルトのプロバイダーでは、App_data フォルダー内のファイル ベースのデータベースか SQL Server のローカル SQLExpress インスタンスのどちらかを使用する LocalSqlServer 接続文字列が使われます。 LocalSqlServer 接続文字列と SqlProvider は両方ともグローバル Web.config ファイルで構成されています。
グローバル Web.config ファイル内の LocalSqlServer 接続文字列は次のようになります。
<connectionStrings>
<add name="LocalSqlServer"
connectionString="data source=.\SQLEXPRESS;
Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;
User Instance=true"
providerName="System.Data.SqlClient" />
</connectionStrings>
別の SQL Server インスタンスを使用する場合は、%windir%\Microsoft.Net\Framework\v2.0.* フォルダーにある Aspnet_regsql.exe ツールを使用する必要があります。 Aspnet_regsql.exe ツールを使用して SQL Server インスタンスにカスタム ASPNETDB データベースを生成してから、アプリケーション構成ファイルに接続文字列を追加し、新しい接続文字列を使用してプロバイダーを追加します。 ASPNETDB データベースを作成したら、eventMapping を sqlProvider にリンクするルールを設定する必要があります。
デフォルトの SqlProvider を使用する場合でも、独自のプロバイダーを構成する場合でも、プロバイダーとイベント マップをリンクするルールを追加する必要があります。 次のルールでは、上記で作成した新しいプロバイダーを All Events イベント マップにリンクします。 このルールでは、WebBaseEvent に基づいてすべてのイベントをログに記録し、MYASPNETDB 接続文字列を使用する MySqlWebEventProvider に送信します。 次のコードでは、プロバイダーをイベント マップとリンクするルールを追加します。
<healthMonitoring>
<rules>
<add name="All Events" eventName="All Events"
provider="MySqlWebEventProvider" profile="Critical"/>
</rules>
</healthMonitoring>
エラーのみを SQL Server に送信する場合は、次のルールを追加できます。
<add name="All Errors"
eventName="All Errors"
provider="MySqlWebEventProvider"
profile="Critical"/>
イベントを WMI に転送する方法
イベントを WMI に転送することもできます。 WMI プロバイダーは、既定ではグローバル Web.config ファイルで構成されています。
次のコード例では、WMI にイベントを転送するルールを追加します。
<providers>
<add name="WmiWebEventProvider"
type="System.Web.Management.WmiWebEventProvider,System.Web,
Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
eventMapping をプロバイダーに関連付けるルールと、イベントをリッスンする WMI リスナー アプリケーションを追加する必要があります。 次のコード例では、WMI プロバイダーを All Events イベント マップにリンクするルールを追加します。
<rules>
<add name="All Events"
eventName="All Events" provider="WmiWebEventProvider"
profile="Critical" />
</rules>
イベントをメールに転送する方法
イベントをメールに転送することもできます。 SQL Server またはイベント ログにより適した多くの情報を意図せずに自身に送信してしまう場合があるため、メール プロバイダーにマップするイベント ルールに注意してください。 メール プロバイダーには次の 2 つがあります: SimpleMailWebEventProvider と TemplatedMailWebEventProvider。 どちらも TemplatedMailWebEventProvider でのみ使用できる "template" および "detailedTemplateErrors" 属性を除いて、それぞれが同一の構成属性を持っています。
Note
これらのメール プロバイダーはいずれも構成されていません。 Web.config ファイルに追加する必要があります。
これら 2 つのメール プロバイダーの主な違いは、SimpleMailWebEventProvider では変更できない汎用テンプレートでメールが送信されることです。 サンプルの Web.config ファイルでは、次のルールを使用して、構成済みのプロバイダーの一覧にこのメール プロバイダーを追加します。
<add name="mySimple-mailWebEventProvider"
type="System.Web.Management.Simple-mailWebEventProvider"
to="e-mail@foo.com" from="e-mail@foo.com"
maxMessagesPerNotification="1" maxEventsPerMessage="10"
buffer="true" bufferMode="Critical Notification"
subjectPrefix="Web Events"/>
メール プロバイダーを All Events イベント マップに結び付けるために、次のルールも追加します。
<add name="All Events" eventName="All Events"
provider="mySimple-mailWebEventProvider" profile="Critical"/>
ASP.NET 2.0 のトレース
ASP.NET 2.0 のトレースには、3 つの主要な機能強化があります。
- 統合されたトレース機能
- トレース メッセージへのプログラムによるアクセス
- 向上したアプリケーション レベルのトレース
統合されたトレース機能
System.Diagnostics.Trace クラスによって生成されたメッセージを ASP.NET トレース出力にルーティングし、ASP.NET トレースによって生成されたメッセージを System.Diagnostics.Trace にルーティングできるようになりました。 ASP.NET インストルメンテーション イベントを System.Diagnostics.Trace に転送することもできます。 この機能は、<trace> 要素の新しい writeToDiagnosticsTrace 属性によって提供されます。 このブール値が true の場合、ASP.NET トレース メッセージは、トレース メッセージを表示するために登録されたすべてのリスナーで使用するために、System.Diagnostics トレース インフラストラクチャへ転送されます。
トレース メッセージへのプログラムによるアクセス
ASP.NET 2.0 では、TraceContextRecord クラスと TraceRecords コレクションを介して、すべてのトレース メッセージにプログラムでアクセスできます。 トレース メッセージにアクセスする最も効率的な方法は、TraceContextEventHandler デリゲート (ASP.NET 2.0 の新機能) を登録して、新しい TraceFinished イベントを処理することです。 その後、必要に応じてトレース メッセージをループ処理できます。
次のコード サンプルは、これを示しています。
void Page_Load(object sender, EventArgs e) {
// Register a handler for the TraceFinished event.
Trace.TraceFinished += new
TraceContextEventHandler(this.OnTraceFinished);
// Write a trace message.
Trace.Write("Web Forms Infrastructure Methods",
"USERMESSAGE: Page_Load complete.");
}
// A TraceContextEventHandler for the TraceFinished event.
void OnTraceFinished(object sender, TraceContextEventArgs e) {
TraceContextRecord r = null;
// Iterate through the collection of trace records and write
// them to the response stream.
foreach (object o in e.TraceRecords) {
r = (TraceContextRecord)o;
Response.Write(String.Format("trace message: {0} <BR>",
r.Message));
}
}
上記の例では、TraceRecords コレクションをループ処理してから、それぞれのメッセージを応答ストリームに書き込みます。
向上したアプリケーション レベルのトレース
<trace> 要素の新しい mostRecent 属性の導入により、アプリケーション レベルのトレースが向上しています。 この属性では、最新のアプリケーション レベルのトレース出力を表示し、requestLimit で示される制限を超えた以前のトレース データを破棄するかどうかを指定します。 false の場合、requestLimit 属性に達するまで、要求のトレース データが表示されます。
ASP.NET コマンド ライン ツール
ASP.NET の構成に役立つコマンド ライン ツールがいくつかあります。 ASP.NET 開発者は、aspnet_regiis.exe ツールに精通している必要があります。 ASP.NET 2.0 には、構成に役立つコマンド ライン ツールが他に 3 つ用意されています。
次のコマンド ライン ツールを使用できます。
| ツール | 使用する方法 |
|---|---|
| aspnet_regiis.exe | ASP.NET を IIS に登録できるようにします。 ASP.NET 2.0 に付属するこのツールには、2 つのバージョンがあります。1 つは 32 ビット システム用 (Framework フォルダー内) で、もう 1 つは 64 ビット システム用 (Framework64 フォルダー内) です。64 ビット バージョンは、32 ビット OS にはインストールされません。 |
| aspnet_regsql.exe | ASP.NET SQL Server 登録ツールは、ASP.NET の SQL Server プロバイダーで使用する Microsoft SQL Server データベースを作成するか、既存のデータベースでオプションを追加または削除するために使用されます。 Aspnet_regsql.exe ファイルは、Web サーバーの [drive:]\WINDOWS\Microsoft.NET\Framework\versionNumber フォルダーにあります。 |
| aspnet_regbrowsers.exe | ASP.NET ブラウザー登録ツールでは、システム全体のすべてのブラウザー定義を解析してアセンブリにコンパイルし、そのアセンブリをグローバル アセンブリ キャッシュにインストールします。 このツールでは、NET Framework Browsers サブディレクトリからのブラウザー定義ファイル (.BROWSER ファイル) を使用します。 また、このツールは、%SystemRoot%\Microsoft.NET\Framework\version\ ディレクトリにあります。 |
| aspnet_compiler.exe | ASP.NET コンパイル ツールを使用すると、ASP.NET Web アプリケーションをインプレースで、またはターゲットの場所 (運用サーバーなど) への展開のためにコンパイルできます。 インプレースでのコンパイルは、アプリケーションのパフォーマンスを支援します。その理由として、アプリケーションのコンパイル中に、エンド ユーザーがアプリケーションへの最初の要求で遅延を回避できることが挙げられます。 |
aspnet_regiis.exe ツールは ASP.NET 2.0 の新機能ではないため、ここでは説明しません。
ASP.NET SQL Server登録ツール - aspnet_regsql.exe
ASP.NET SQL Server 登録ツールを使用して、いくつかの種類のオプションを設定できます。 SQL 接続の指定、情報を管理するために SQL Server を使用する ASP.NET アプリケーション サービスの指定、SQL キャッシュの依存関係に使用するデータベースまたはテーブルの指定、SQL Server を使用してプロシージャとセッション状態を保存するためのサポートの追加または削除を行うことができます。
いくつかの ASP.NET アプリケーション サービスは、データ ソースからのデータの保存と取得を管理するために、プロバイダーに依存しています。 各プロバイダーは、データ ソースに固有です。 ASP.NET には、次の ASP.NET 機能用の SQL Server プロバイダーが含まれます。
- メンバーシップ (SqlMembershipProvider クラス)。
- ロール管理 (SqlRoleProvider クラス)。
- プロファイル (SqlProfileProvider クラス)。
- Web パーツのパーソナル化 (SqlPersonalizationProvider クラス)。
- Web イベント (SqlWebEventProvider クラス)。
ASP.NET をインストールすると、サーバーの Machine.config ファイルには、プロバイダーに依存する各 ASP.NET 機能に対して SQL Server プロバイダーを指定する構成要素が含まれています。 これらのプロバイダーは、既定では SQL Server Express 2005 のローカル ユーザー インスタンスに接続するように構成されています。 プロバイダーで使用するデフォルトの接続文字列を変更する場合は、マシンの構成で構成されているいずれかの ASP.NET 機能を使用する前に、Aspnet_regsql.exe を使用して、SQL Server データベースと選んだ機能のデータベース要素をインストールする必要があります。 SQL 登録ツールで指定したデータベースがまだ存在しない場合 (コマンド ラインで指定されていない場合は aspnetdb がデフォルトのデータベースになります)、現在のユーザーには SQL Server でのデータベースの作成、およびデータベース内でのスキーマ要素の作成のための権限が必要です。
SQL キャッシュ依存関係
ASP.NET 出力キャッシュの高度な機能は、SQL キャッシュの依存関係です。 SQL キャッシュ依存関係は、次の 2 種類の操作モードをサポートしています: テーブル ポーリングの ASP.NET の実装を使用するモードと、SQL Server 2005 のクエリ通知機能を使用する 2 つ目のモード。 SQL 登録ツールを使用して、操作のテーブル ポーリング モードを構成できます。
セッションの状態
既定では、セッション状態の値と情報は、ASP.NET プロセス内のメモリに保存されます。 または、セッション データを SQL Server データベースに保存して、複数の Web サーバーで共有できます。 SQL 登録ツールでセッション状態に指定したデータベースがまだ存在しない場合、現在のユーザーには、SQL Server でのデータベースの作成と、データベース内でのスキーマ要素の作成のための権限が必要です。 データベースが存在する場合、現在のユーザーには、既存のデータベースにスキーマ要素を作成する権限が必要です。
SQL Server にセッション状態データベースをインストールするには、Aspnet_regsql.exe ツールを実行し、コマンドを使用して次の情報を指定します。
- -S オプションを使用した SQL Server インスタンスの名前。
- SQL Server を実行中のコンピューターにデータベースを作成するためのアクセス許可を持つアカウントのログオン資格情報。 -E オプションを使用して現在ログオンしているユーザーを使用するか、-U オプションを使用してユーザー ID と -P オプションを指定してパスワードを指定します。
- セッション状態データベースを追加するための -ssadd コマンド ライン オプション。
既定では、SQL Server 2005 Express Edition を実行中のコンピューターに、Aspnet_regsql.exe ツールを使用してセッション状態データベースをインストールすることはできません。
ASP.NET ブラウザー登録ツール - aspnet_regbrowsers.exe
ASP.NET バージョン 1.1 では、Machine.config ファイルに <browserCaps> というセクション含まれていました。 このセクションには、正規表現に基づいてさまざまなブラウザーの構成を定義する一連の XML エントリが含まれていました。 ASP.NET バージョン 2.0 では、新しい .BROWSER ファイルで XML エントリを使用して特定のブラウザーのパラメーターを定義します。 新しいブラウザーに情報を追加するには、システム上の %SystemRoot%\Microsoft.NET\Framework\version\CONFIG\Browsers にあるフォルダーに新しい .BROWSER ファイルを追加します。
ブラウザー情報が必要になるたびにアプリケーションで .config ファイルを読み取ることがないため、新しい .BROWSER ファイルを作成して、Aspnet_regbrowsers.exe を実行し、必要な変更をアセンブリに追加できます。 これにより、サーバーで新しいブラウザー情報にすぐにアクセスできるため、情報を取得するためにいずれのアプリケーションもシャットダウンする必要はありません。 アプリケーションでは、現在の HttpRequest の Browser プロパティを使用してブラウザー機能にアクセスできます。
aspnet_regbrowser.exe の実行時には、次のオプションを利用できます。
| オプション | 説明 |
|---|---|
| -? | コマンド ウィンドウに Aspnet_regbbrowsers.exe ヘルプ テキストを表示します。 |
| -i | ランタイム ブラウザー機能アセンブリを作成し、グローバル アセンブリ キャッシュにインストールします。 |
| -u | グローバル アセンブリ キャッシュからランタイム ブラウザー機能アセンブリをアンインストールします。 |
ASP.NET コンパイル ツール - aspnet_compiler.exe
ASP.NET コンパイル ツールは、次の 2 つの一般的な方法で使用できます: インプレースでのコンパイルと、ターゲット出力ディレクトリが指定された展開のためのコンパイル。
インプレースでのアプリケーションのコンパイル
ASP.NET コンパイル ツールでは、アプリケーションをインプレースでコンパイルできます。つまり、アプリケーションに対して複数の要求を行う動作を模倣するため、通常のコンパイルが発生します。 プリコンパイル済みサイトのユーザーは、最初の要求時にページをコンパイルすると発生する遅延を回避できます。
サイトをインプレースでプリコンパイルすると、次の項目が適用されます。
- サイトで、そのファイルおよびディレクトリ構造が保持される。
- サーバー上のサイトで使用するすべてのプログラミング言語に対してコンパイラが必要。
- いずれかのファイルでコンパイルに失敗すると、サイト全体でコンパイルに失敗する。
新しいソース ファイルを追加した後に、アプリケーションをインプレースで再コンパイルすることもできます。 -c オプションを含めない限り、ツールでは新規または変更されたファイルのみをコンパイルします。
Note
入れ子になったアプリケーションを含むアプリケーションをコンパイルしても、入れ子になったアプリケーションはコンパイルされません。 入れ子になったアプリケーションは個別にコンパイルする必要があります。
展開のためのアプリケーションのコンパイル
targetDir パラメーターを指定して、展開 (ターゲットの場所へのコンパイル) のためにアプリケーションをコンパイルします。 targetDir を Web アプリケーションの最終的な保存先にすることも、コンパイルしたアプリケーションをさらに展開することもできます。 -u オプションを使用すると、コンパイルしたアプリケーション内の特定のファイルを再コンパイルせずに変更できるように、アプリケーションがコンパイルされます。 Aspnet_compiler.exe では、静的および動的なファイルの種類を区別し、結果として得られるアプリケーションの作成時に異なる方法で処理します。
- 静的ファイルの種類とは、名前に .css、.gif、.htm、.html、.jpg、.js といった拡張子が付くファイルなど、関連付けられたコンパイラまたはビルド プロバイダーを持たないものを指します。 これらのファイルは単にターゲットの場所にコピーされ、ディレクトリ構造内の相対位置は保持されます。
- 動的ファイルの種類とは、asax、.ascx、.ashx、.aspx、.browser、.master といった ASP.NET に固有のファイル名拡張子が付いたファイルなど、関連付けられたコンパイラまたはビルド プロバイダーを持つものを指します。 ASP.NET コンパイル ツールでは、これらのファイルからアセンブリを生成します。 -u オプションを省略すると、ファイル名拡張子 .COMPILED を持ち、元のソース ファイルをアセンブリにマップするファイルも同ツールで作成されます。 アプリケーション ソースのディレクトリ構造を確実に保持するために、同ツールでターゲット アプリケーション内の対応する場所にプレースホルダー ファイルを生成します。
-u オプションを使用して、コンパイル済みアプリケーションのコンテンツを変更できることを示す必要があります。 そのようにしない場合、後続の変更は無視されるか、実行時エラーを引き起こす可能性があります。
次の表では、-u オプションが含まれている場合に、ASP.NET コンパイル ツールでさまざまなファイルの種類を処理する方法について説明します。
| ファイルの種類 | コンパイラのアクション |
|---|---|
| .ascx、.aspx、.master | これらのファイルはマークアップとソース コードに分割されます。これらには、分離コード ファイルと <script runat="server"> 要素で囲まれたコードの両方が含まれます。 ソース コードは、ハッシュ アルゴリズムから派生した名前を持つアセンブリにコンパイルされ、アセンブリは Bin ディレクトリに配置されます。 いずれのインライン コード (つまり、角かっこ <% および %> の間で囲まれたコード) もマークアップに含まれており、コンパイルされません。 ソース ファイルと同じ名前の新しいファイルは、マークアップを含めるために作成されており、対応する出力ディレクトリに配置されます。 |
| .ashx、.asmx | これらのファイルはコンパイルされず、そのまま出力ディレクトリに移行されて、コンパイルされません。 ハンドラー コードをコンパイルする必要がある場合は、そのコードを App_Code ディレクトリ内のソース コード ファイルに配置します。 |
| .cs、.vb、.jsl、.cpp (前述のファイルの種類の分離コード ファイルは含まれません) | これらのファイルはコンパイルされ、それらを参照するアセンブリにリソースとして含まれます。 ソース ファイルは出力ディレクトリにコピーされません。 コード ファイルは参照されていない場合、コンパイルされません。 |
| カスタム ファイルの種類 | これらのファイルはコンパイルされません。 これらのファイルは、対応する出力ディレクトリにコピーされます。 |
| App_Code サブディレクトリ内のソース コード ファイル | これらのファイルはアセンブリにコンパイルされ、Bin ディレクトリに配置されます。 |
| App_GlobalResources サブディレクトリ内の .resx および .resource ファイル | これらのファイルはアセンブリにコンパイルされ、Bin ディレクトリに配置されます。 メインの出力ディレクトリの下に App_GlobalResources サブディレクトリは作成されません。また、ソース ディレクトリにある .resx または .resources ファイルは出力ディレクトリにコピーされません。 |
| App_LocalResources サブディレクトリ内の .resx および .resource ファイル | これらのファイルはコンパイルされず、対応する出力ディレクトリにコピーされます。 |
| App_Themes サブディレクトリ内の .skin ファイル | .skin ファイルと静的テーマ ファイルはコンパイルされず、対応する出力ディレクトリにコピーされます。 |
| .browser Web.config 静的ファイルの種類のアセンブリが Bin ディレクトリに既に存在する | これらのファイルは、そのまま出力ディレクトリにコピーされます。 |
次の表では、-u オプションが省略されている場合に、ASP.NET コンパイル ツールでさまざまなファイルの種類を処理する方法について説明します。
| ファイルの種類 | コンパイラのアクション |
|---|---|
| .aspx、.asmx、.ashx、.master | これらのファイルはマークアップとソース コードに分割されます。これらには、分離コード ファイルと <script runat="server"> 要素で囲まれたコードの両方が含まれます。 ソース コードは、ハッシュ アルゴリズムから派生した名前でアセンブリにコンパイルされます。 結果として得られるアセンブリは Bin ディレクトリに配置されます。 いずれのインライン コード (つまり、角かっこ <% および %> の間で囲まれたコード) もマークアップに含まれており、コンパイルされません。 コンパイラでは、ソース ファイルと同じ名前のマークアップを含む新しいファイルを作成します。 結果として得られるこれらのファイルは Bin ディレクトリに配置されます。 コンパイラでは、ソース ファイルと同じ名前を持つものの、マッピング情報を含む拡張子 .COMPILED が付いたファイルも作成されます。 .COMPILED ファイルは、ソース ファイルの元の場所に対応する出力ディレクトリに配置されます。 |
| .ascx | これらのファイルは、マークアップとソース コードに分割されます。 ソース コードはアセンブリにコンパイルされ、ハッシュ アルゴリズムから派生した名前で Bin ディレクトリに配置されます。 マークアップ ファイルは生成されません。 |
| .cs、.vb、.jsl、.cpp (前述のファイルの種類の分離コード ファイルは含まれません) | .ascx、.ashx、.aspx ファイルから生成されたアセンブリによって参照されるソース コードは、アセンブリにコンパイルされ、Bin ディレクトリに配置されます。 ソース ファイルはコピーされません。 |
| カスタム ファイルの種類 | これらのファイルは、動的ファイルと同じようにコンパイルされます。 コンパイラでは、基になっているファイルの種類に応じて、マッピング ファイルを出力ディレクトリに配置できます。 |
| App_Code サブディレクトリ内のファイル | このサブディレクトリ内のソース コード ファイルは、アセンブリにコンパイルされ、Bin ディレクトリに配置されます。 |
| App_GlobalResources サブディレクトリ内のファイル | これらのファイルはアセンブリにコンパイルされ、Bin ディレクトリに配置されます。 メインの出力ディレクトリの下に App_GlobalResources サブディレクトリは作成されません。 構成ファイルで appliesTo="All" が指定されている場合、.resx および .resources ファイルは出力ディレクトリにコピーされます。 BuildProvider によって参照されている場合は、コピーされません。 |
| App_LocalResources サブディレクトリ内の .resx および .resource ファイル | これらのファイルは、一意の名前を持つアセンブリにコンパイルされ、Bin ディレクトリに配置されます。 .resx または .resource ファイルは出力ディレクトリにコピーされません。 |
| App_Themes サブディレクトリ内の .skin ファイル | テーマはアセンブリにコンパイルされ、Bin ディレクトリに配置されます。 スタブ ファイルは .skin ファイル用に作成され、対応する出力ディレクトリに配置されます。 静的ファイル (.css など) が出力ディレクトリにコピーされます。 |
| .browser Web.config 静的ファイルの種類のアセンブリが Bin ディレクトリに既に存在する | これらのファイルは、そのまま出力ディレクトリにコピーされます。 |
固定のアセンブリ名
MSI Windows インストーラーを使用して Web アプリケーションを展開する場合など、一部のシナリオでは、一貫性のあるファイル名とコンテンツに加えて、一貫性のあるディレクトリ構造も使用し、アセンブリまたは更新の構成設定を識別する必要があります。 そうした場合には、複数のページがアセンブリにコンパイルされる場所を使用するのではなく、-fixednames オプションを使用して、ASP.NET コンパイル ツールで各ソース ファイルのアセンブリをコンパイルするように指定できます。 これにより、アセンブリの数が多くなる可能性があるため、スケーラビリティに懸念がある場合は、このオプションを慎重に使用する必要があります。
厳密な名前のコンパイル
-aptca、-delaysign、-keycontainer、-keyfile の各オプションが用意されているため、厳密名ツール (Sn.exe) を個別に使用することなく、Aspnet_compiler.exe を使用して厳密な名前の付いたアセンブリを作成できます。 これらのオプションはそれぞれ、AllowPartiallyTrustedCallersAttribute、AssemblyDelaySignAttribute、AssemblyKeyNameAttribute、AssemblyKeyFileAttribute に対応しています。
これらの属性についての説明は、このコースの範囲外です。
ラボ
次のそれぞれのラボは、前のラボに基づいており、 順番に実行する必要があります。
ラボ 1: 構成 API の使用
- mod9lab という新しい Web サイトを作成します。
- 新しい Web 構成ファイルをサイトに追加します。
- web.config ファイルに以下を追加します。
<authorization>
<deny users="?"/>
</authorization>
<identity impersonate="true"/>
これにより、web.config ファイルに対する変更を保存するアクセス許可が確実に付与されます。
- 新しいラベル コントロールを Default.aspx に追加し、ID を lblDebugStatus に変更します。
- 新しいボタン コントロールを Default.aspx に追加します。
- ボタン コントロールの ID を btnToggleDebug に、Text を「Toggle Debug Status」に変更します。
- Default.aspx の分離コード ファイルのコード ビューを開き、System.Web.Configuration の using ステートメントを次のように追加します。
using System.Web.Configuration;
- 以下に示すように、クラスと Page_Init メソッドに 2 つのプライベート変数を追加します。
public partial class _Default : System.Web.UI.Page {
private bool _debugStatus;
private CompilationSection compilation;
private Configuration config;
protected void Page_Init(object sender, EventArgs e) {
config = WebConfigurationManager.OpenWebConfiguration("/mod9lab");
compilation =
(CompilationSection)config.GetSection("system.web/compilation");
_debugStatus = compilation.Debug;
}
}
- 次のコードを Page_Load に追加します。
lblDebugStatus.Text = "Debug set to: " + _debugStatus.ToString();
- default.aspx を保存して参照します。 ラベル コントロールに現在のデバッグ状態が表示されていることに注意してください。
- デザイナーでボタン コントロールをダブルクリックして、次のコードをボタン コントロールのクリック イベントに追加します。
compilation.Debug = !_debugStatus;
config.Save();
lblDebugStatus.Text = "Debug set to: " + compilation.Debug.ToString();
- default.aspx を保存して参照し、ボタンをクリックします。
- 各ボタンをクリックした後に web.config ファイルを開き、<compilation> セクションで debug 属性を確認します。
ラボ 2: アプリケーションの再起動のログ記録
このラボでは、イベント ビューアーでアプリケーションのシャットダウン、起動、再コンパイルのログ記録を切り替えられるようにするコードを作成します。
- DropDownList を default.aspx に追加して、ID を ddlLogAppEvents に変更します。
- DropDownList の AutoPostBack プロパティを true に設定します。
- DropDownList の Items コレクションに 3 つの項目を追加します。 最初の項目の Text を「Select Value」 にして、Value を -1 にします。 2 番目の項目の Text と Value を True にして、3 番目の項目の Text と Value を False にします。
- default.aspx に新しいラベルを追加します。 ID を lblLogAppEvents に変更します。
- default.aspx の分離コード ビューを開き、以下に示すように HealthMonitoringSection 型の変数の新しい宣言を追加します。
public partial class _Default : System.Web.UI.Page {
private bool _debugStatus;
private CompilationSection compilation;
private Configuration config;
// new variable below
private HealthMonitoringSection health;
}
- Page_Init の既存のコードに次のコードを追加します。
health = (HealthMonitoringSection)config.GetSection("system.web/healthMonitoring");
- DropDownList をダブルクリックして、SelectedIndexChanged イベントに次のコードを追加します。
if (ddlLogAppEvents.SelectedValue != "-1") {
if (Convert.ToBoolean(ddlLogAppEvents.SelectedValue)) {
RuleSettings appRules = new
RuleSettings("AppRestartEvents",
"Application Lifetime Events",
"EventLogProvider");
health.Rules.Add(appRules);
config.Save();
} else {
health.Rules.Remove("AppRestartEvents");
config.Save();
}
}
default.aspx を参照します。
ドロップダウンを False に設定します。
イベント ビューアーでアプリケーション ログをクリアします。
ボタンをクリックして、アプリケーションの Debug 属性を変更します。
イベント ビューアーでアプリケーション ログを更新します。
- イベントはログに記録されましたか?
- なぜそうなのでしょう? または、なぜそうではないのでしょう?
ドロップダウンを True に設定します。
ボタンをクリックして、アプリケーションの Debug 属性を切り替えます。
イベント ビューアーでアプリケーション ログを更新します。
- イベントはログに記録されましたか?
- アプリのシャットダウンの理由は何でしたか?
ログ記録のオンとオフを試して、web.config ファイルに加えられた変更を確認します。
詳細情報:
ASP.NET 2.0 のプロバイダー モデルを使用すると、アプリケーションのインストルメンテーションだけでなく、メンバーシップやプロファイルなど、他の多くの用途に対しても独自のプロバイダーを作成できます。テキスト ファイルにアプリケーション イベントのログを記録するカスタム プロバイダーの記述の詳細については、このリンクを参照してください。