構成とインストルメンテーション

作成者: Microsoft

注意

この記事が作成されて以来、ASP.NET メンバーシップ プロバイダーは 、ASP.NET ID に置き換えられました。 この記事の執筆時点で取り上げられたメンバーシップ プロバイダーではなく 、ASP.NET ID プラットフォームを使用するようにアプリを更新することを強くお勧めします。 ASP.NET ID には、ASP.NET メンバーシップ システムに比して、次のような多くの利点があります。

  • パフォーマンスの向上
  • 拡張性とテスト容易性の向上
  • OAuth、OpenID Connect、および 2 要素認証のサポート
  • クレームベースの ID のサポート
  • ASP.Net Core との相互運用性の向上

ASP.NET 2.0 では、構成とインストルメンテーションに大きな変更があります。 新しい ASP.NET 構成 API を使用すると、構成の変更をプログラムで行うことができます。 さらに、多くの新しい構成設定が存在すると、新しい構成とインストルメンテーションが可能になります。

ASP.NET 2.0 では、構成とインストルメンテーションに大きな変更があります。 新しい ASP.NET 構成 API を使用すると、構成の変更をプログラムで行うことができます。 さらに、多くの新しい構成設定が存在すると、新しい構成とインストルメンテーションが可能になります。

このモジュールでは、ASP.NET 構成ファイルの読み取りと書き込みに関連する構成 API の ASP.NET について説明します。また、ASP.NET インストルメンテーションについても説明します。 また、ASP.NET トレースで使用できる新機能についても説明します。

ASP.NET 構成 API

ASP.NET 構成 API を使用すると、単一のプログラミング インターフェイスを使用して、アプリケーション構成データを開発、デプロイ、管理できます。 構成 API を使用すると、構成ファイル内の XML を直接編集することなく、プログラムで完全な ASP.NET 構成を開発および変更できます。 さらに、構成 API は、開発するコンソール アプリケーションとスクリプト、Web ベースの管理ツール、および Microsoft 管理コンソール (MMC) スナップインで使用できます。

次の 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 は、コンピューターでの構成ファイルの作成をサポートし、複数のコンピューター間で構成スクリプトを実行することで、展開を簡略化します。

注意

構成 API では、IIS アプリケーションの作成はサポートされていません。

ローカルとリモートの構成設定の操作

Configuration オブジェクトは、コンピューターなどの特定の物理エンティティ、またはアプリケーションや Web サイトなどの論理エンティティに適用される構成設定のマージされたビューを表します。 指定した論理エンティティは、ローカル コンピューターまたはリモート サーバー上に存在できます。 指定したエンティティに構成ファイルが存在しない場合、Configuration オブジェクトは、Machine.config ファイルで定義されている既定の構成設定を表します。

Configuration オブジェクトは、次のクラスから開いている構成メソッドのいずれかを使用して取得できます。

  1. エンティティがクライアント アプリケーションの場合は ConfigurationManager クラス。
  2. エンティティが Web アプリケーションの場合は、WebConfigurationManager クラス。

これらのメソッドは Configuration オブジェクトを返します。これにより、基になる構成ファイルを処理するために必要なメソッドとプロパティが提供されます。 これらのファイルにアクセスして、読み取りまたは書き込みを行うことができます。

読み取り中

構成情報を読み取るには、GetSection メソッドまたは GetSectionGroup メソッドを使用します。 読み取りを行うユーザーまたはプロセスには、階層内のすべての構成ファイルに対する読み取りアクセス許可が必要です。

注意

path パラメーターを受け取る静的な GetSection メソッドを使用する場合、path パラメーターはコードが実行されているアプリケーションを参照する必要があります。 それ以外の場合、 パラメーターは無視され、現在実行中のアプリケーションの構成情報が返されます。

書き込み

Save メソッドのいずれかを使用して、構成情報を書き込みます。 書き込むユーザーまたはプロセスには、現在の構成階層レベルの構成ファイルとディレクトリに対する書き込みアクセス許可と、階層内のすべての構成ファイルに対する読み取りアクセス許可が必要です。

指定したエンティティの継承された構成設定を表す構成ファイルを生成するには、次のいずれかの save-configuration メソッドを使用します。

  1. 新しい構成ファイルを作成する Save メソッド。
  2. 別の場所に新しい構成ファイルを生成する 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 つあります。

  1. OpenWebConfiguration メソッドを使用して Configuration オブジェクトを取得します。
  2. 構成ファイル内の目的のセクションへの参照を取得します。
  3. 構成ファイルから目的の情報を読み取ります。

Configuration オブジェクトが表すは、特定の構成ファイルを表していません。 代わりに、コンピューター、アプリケーション、または Web サイトの構成のマージされたビューを表します。 次のコード サンプルでは、 ProductInfo という Web アプリケーションの構成を表す Configuration オブジェクトをインスタンス化します。

Configuration config = WebConfigurationManager.OpenWebConfiguration("/ProductInfo);

注意

/ProductInfo パスが存在しない場合、上記のコードは、machine.config ファイルで指定されている既定の構成を返します。

Configuration オブジェクトを取得したら、GetSection メソッドまたは GetSectionGroup メソッドを使用して、構成設定をドリルダウンできます。 次の例では、上記の ProductInfo アプリケーションの偽装設定への参照を取得します。

Configuration config =
    WebConfigurationManager.OpenWebConfiguration("/ProductInfo);
IdentitySection section =
   (IdentitySection)config.GetSection("system.web/identity");

ASP.NET 構成ファイルへの書き込み

構成ファイルからの読み取りと同様に、WebConfigurationManager クラスは、Asp.NET 構成ファイルへの書き込みの中核となります。 ASP.NET 構成ファイルに書き込むには、3 つの手順もあります。

  1. OpenWebConfiguration メソッドを使用して Configuration オブジェクトを取得します。
  2. 構成ファイル内の目的のセクションへの参照を取得します。
  3. Save または SaveAs メソッドを使用して、構成ファイルから目的の情報を書き込みます。

次のコードは、コンパイル>要素の 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!");
}

このコードを実行すると、webApp アプリケーションの<web.config ファイルに対して、コンパイル>要素の debug 属性が 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 データベースに送信するルールを設定できます。 また、ユーザーが 1 行に複数回ログオンできない場合にイベントを発生させ、メール ベースのプロバイダーを使用するようにイベントを設定することもできます。

既定のプロバイダーとイベントの構成は、グローバル Web.config ファイルに格納されます。 グローバル Web.config ファイルには、Machine.config ファイルに格納されたすべての Web ベースの設定が ASP.NET 1x に格納されます。 グローバル 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 をプロバイダーにリンクします。
バッファリング イベントをプロバイダーにフラッシュする頻度を決定するために、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 ファイルで構成されます。 既定では、 WebBaseErrorEventWebFailureAuditEvent に基づくすべてのイベントがログに記録されます。 追加のルールを追加して、追加情報をイベント ログに記録できます。 たとえば、すべてのイベント (つまり、WebBaseEvent に基づくすべてのイベント) をログに記録する場合は、Web.config ファイルに次の規則を追加できます。

<healthMonitoring>
    <rules>
        <add name="All Events" eventName="All Events"
             provider="EventLogProvider" profile="Critical" />
    </rules>
</healthMonitoring>

このルールは、 すべてのイベント イベント マップをイベント ログ プロバイダーにリンクします。 eventMapping とプロバイダーの両方がグローバル Web.config ファイルに含まれています。

イベントをSQL Serverに格納する方法

このメソッドは、Aspnet_regsql.exe ツールによって生成される ASPNETDB データベースを使用します。 既定のプロバイダーは LocalSqlServer 接続文字列を使用します。この接続文字列では、App_data フォルダー内のファイル ベースのデータベースまたは SQL Server のローカル SQLExpress インスタンスが使用されます。 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 を使用する場合でも、独自のプロバイダーを構成する場合でも、プロバイダーをイベント マップにリンクするルールを追加する必要があります。 次の規則は、上記で作成した新しいプロバイダーを [すべてのイベント] イベント マップにリンクします。 このルールは、 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 プロバイダーを すべてのイベント イベント マップにリンクする規則を追加します。

<rules>
    <add name="All Events"
      eventName="All Events" provider="WmiWebEventProvider"
        profile="Critical" />
</rules>

イベントをメールに転送する方法

イベントをメールに転送することもできます。 メール プロバイダーにマップするイベント ルールには注意してください。これは、SQL Serverやイベント ログに適した多くの情報を誤って自分に送信する可能性があるためです。 電子メール プロバイダーは 2 つあります。SimpleMailWebEventProvider と TemplatedMailWebEventProvider。 それぞれの構成属性は同じですが、"template" 属性と "detailedTemplateErrors" 属性を除き、どちらも TemplatedMailWebEventProvider でのみ使用できます。

注意

これらのメール プロバイダーはどちらも構成されていません。 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"/>

電子メール プロバイダーを すべてのイベント イベント マップに関連付けるために、次のルールも追加されます。

<add name="All Events" eventName="All Events"
    provider="mySimple-mailWebEventProvider" profile="Critical"/>

ASP.NET 2.0 トレース

ASP.NET 2.0 のトレースには、3 つの主要な機能強化があります。

  1. 統合トレース機能
  2. トレース メッセージへのプログラムによるアクセス
  3. アプリケーション レベルのトレースの改善

統合トレース機能

System.Diagnostics.Trace クラスによって出力されたメッセージをトレース出力を ASP.NET にルーティングし、ASP.NET トレースによって出力されたメッセージを System.Diagnostics.Trace にルーティングできるようになりました。 ASP.NET インストルメンテーション イベントを System.Diagnostics.Trace に転送することもできます。 この機能は、トレース>要素の新しい writeToDiagnosticsTrace 属性<によって提供されます。 このブール値が true の場合、トレース メッセージ ASP.NET トレース メッセージは System.Diagnostics トレース インフラストラクチャに転送され、トレース メッセージを表示するために登録されているリスナーで使用されます。

トレース メッセージへのプログラムによるアクセス

ASP.NET 2.0 では、 TraceContextRecord クラスと TraceRecords コレクションを使用して、すべてのトレース メッセージにプログラムでアクセスできます。 トレース メッセージにアクセスする最も効率的な方法は、新しい TraceFinished イベントを処理するために TraceContextEventHandler デリゲート (ASP.NET 2.0 でも新しい) を登録することです。 その後、必要に応じてトレース メッセージをループ処理できます。

次のコード サンプルは、これを示しています。

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 コレクションをループ処理し、各メッセージを応答ストリームに書き込みます。

Application-Level トレースの改善

アプリケーション レベルのトレースは、トレース>要素の新しい mostRecent 属性の<導入によって改善されます。 この属性は、最新のアプリケーション レベルのトレース出力を表示し、requestLimit によって示される制限を超える古いトレース データを破棄するかどうかを指定します。 false の場合、requestLimit 属性に達するまで、要求のトレース データが表示されます。

ASP.NET コマンド ライン ツール

ASP.NET の構成に役立つコマンド ライン ツールがいくつかあります。 ASP.NET 開発者は、aspnet_regiis.exe ツールに精通している必要があります。 ASP.NET 2.0 には、構成に役立つ他の 3 つのコマンドライン ツールが用意されています。

次のコマンド ライン ツールを使用できます。

ツール 用途
aspnet_regiis.exe IIS への ASP.NET の登録を許可します。 このツールには、ASP.NET 2.0 に付属する 2 つのバージョンがあります。1 つは 32 ビット システム用 (Framework フォルダー内) 用と 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 ブラウザー登録ツールは、システム全体のすべてのブラウザー定義を解析してアセンブリにコンパイルし、アセンブリをグローバル アセンブリ キャッシュにインストールします。 このツールでは、ブラウザー定義ファイル (。BROWSER ファイル) を.NET Framework 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 プロバイダーが含まれています。

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 キャッシュ依存関係では、テーブル ポーリングの ASP.NET 実装を使用するモードと、SQL Server 2005 のクエリ通知機能を使用する 2 つ目のモードという 2 つの異なる操作モードがサポートされています。 SQL 登録ツールを使用して、テーブル ポーリング モードの操作を構成できます。

セッションの状態

既定では、セッション状態の値と情報は、ASP.NET プロセス内のメモリに格納されます。 または、セッション データを複数の Web サーバーで共有できるSQL Server データベースに格納することもできます。 SQL 登録ツールを使用してセッション状態に指定したデータベースがまだ存在しない場合、現在のユーザーには、SQL Serverにデータベースを作成する権限と、データベース内にスキーマ要素を作成する権限が必要です。 データベースが存在する場合、現在のユーザーは既存のデータベースにスキーマ要素を作成する権限を持っている必要があります。

SQL Serverにセッション状態データベースをインストールするには、Aspnet_regsql.exe ツールを実行し、 コマンドで次の情報を指定します。

  • -S オプションを使用して、SQL Server インスタンスの名前を指定します。
  • SQL Serverを実行しているコンピューターにデータベースを作成するアクセス許可を持つアカウントのログオン資格情報。 -E オプションを使用して現在ログオンしているユーザーを使用するか、-U オプションを使用してユーザー ID と -P オプションを使用してパスワードを指定します。
  • セッション状態データベースを追加するための -ssadd コマンド ライン オプション。

既定では、Aspnet_regsql.exe ツールを使用して、SQL Server 2005 Express Editionを実行しているコンピューターにセッション状態データベースをインストールすることはできません。

ASP.NET ブラウザー登録ツール - aspnet_regbrowsers.exe

バージョン 1.1 ASP.NET、Machine.config ファイルには browserCaps という <セクションが含まれていました>。 このセクションには、正規表現に基づいてさまざまなブラウザーの構成を定義する一連の XML エントリが含まれていました。 ASP.NET バージョン 2.0 の場合は、新しい です。BROWSER ファイルは、XML エントリを使用して特定のブラウザーのパラメーターを定義します。 新しい ブラウザーに情報を追加する場合は、新しい を追加します。BROWSER ファイルは、システム上の %SystemRoot%\Microsoft.NET\Framework\version\CONFIG\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 オプションを含めない限り、ツールは新しいファイルまたは変更されたファイルのみをコンパイルします。

注意

入れ子になったアプリケーションを含むアプリケーションのコンパイルでは、入れ子になったアプリケーションはコンパイルされません。 入れ子になったアプリケーションは個別にコンパイルする必要があります。

配置用のアプリケーションのコンパイル

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 これらのファイルはマークアップとソース コードに分割されます。これには、分離コード ファイルと、スクリプト 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 これらのファイルはマークアップとソース コードに分割されます。これには、分離コード ファイルと、スクリプト 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 コンパイル ツールで各ソース ファイルのアセンブリをコンパイルするように指定できます。 これにより、多数のアセンブリが発生する可能性があるため、スケーラビリティに関心がある場合は、このオプションを慎重に使用する必要があります。

厳密な名前のコンパイル

Aspnet_compiler.exeを使用して厳密名ツール (Sn.exe) を個別に使用せずに厳密な名前付きアセンブリを作成できるように、-aptca-delaysign-keycontainerおよび -keyfile の各オプションが用意されています。 これらのオプションは、それぞれ AllowPartiallyTrustedCallersAttributeAssemblyDelaySignAttributeAssemblyKeyNameAttributeおよび AssemblyKeyFileAttribute に対応します。

これらの属性については、このコースの範囲外です。

ラボ

次の各ラボは、前のラボに基づいて構築されています。 順番に行う必要があります。

ラボ 1: 構成 API の使用

  1. mod9lab という名前の新しい Web サイトを作成します。
  2. 新しい Web 構成ファイルをサイトに追加します。
  3. web.config ファイルに次を追加します。
<authorization>
    <deny users="?"/>
</authorization>

<identity impersonate="true"/>

これにより、web.config ファイルへの変更を保存するアクセス許可が付与されます。

  1. 新しい Label コントロールを Default.aspx に追加し、ID を lblDebugStatus に変更します。
  2. 新しい Button コントロールを Default.aspx に追加します。
  3. Button コントロールの ID を btnToggleDebug に、テキストを [デバッグ状態の切り替え] に変更します。
  4. Default.aspx の分離コード ファイルのコード ビューを開き、System.Web.Configurationusing ステートメントを次のように追加します。
using System.Web.Configuration;
  1. 次に示すように、クラスと 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;
    }
}
  1. Page_Loadに次のコードを追加します。
lblDebugStatus.Text = "Debug set to: " + _debugStatus.ToString();
  1. default.aspx を保存して参照します。 Label コントロールに現在のデバッグ状態が表示されます。
  2. デザイナーで Button コントロールをダブルクリックし、Button コントロールの Click イベントに次のコードを追加します。
compilation.Debug = !_debugStatus;
config.Save();
lblDebugStatus.Text = "Debug set to: " + compilation.Debug.ToString();
  1. default.aspx を保存して参照し、ボタンをクリックします。
  2. 各ボタンのクリック後にweb.config ファイルを開き、コンパイル> セクションの debug 属性を<確認します。

ラボ 2: アプリケーションの再起動のログ記録

このラボでは、イベント ビューアーでアプリケーションのシャットダウン、スタートアップ、再コンパイルのログ記録を切り替えるコードを作成します。

  1. DropDownList を default.aspx に追加し、ID を ddlLogAppEvents に変更します。
  2. DropDownList の AutoPostBack プロパティを true に設定 します
  3. DropDownList の Items コレクションに 3 つの項目を追加します。 最初の項目の [値選択 ] と値 -1 のテキストを作成します。 2 番目の項目の TextValueを True に し、3 番目のアイテムの TextValue をFalse にします
  4. default.aspx に新しいラベルを追加します。 ID を lblLogAppEvents に変更します。
  5. 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;
}
  1. Page_Initの既存のコードに次のコードを追加します。
health = (HealthMonitoringSection)config.GetSection("system.web/healthMonitoring");
  1. 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();
    }
}
  1. default.aspx を参照します。

  2. ドロップダウンを False に設定 します

  3. イベント ビューアーのアプリケーション ログをクリアします。

  4. ボタンをクリックして、アプリケーションの Debug 属性を変更します。

  5. イベント ビューアーでアプリケーション ログを更新します。

    1. イベントはログに記録されましたか?
    2. なぜそうなのでしょう? または、なぜそうではないのでしょう?
  6. ドロップダウンを True に設定 します。

  7. ボタンをクリックして、アプリケーションの Debug 属性を切り替えます。

  8. イベント ビューアーをアプリケーション ログインに更新します。

    1. イベントはログに記録されましたか?
    2. アプリのシャットダウンの理由は何でしたか?
  9. ログ記録のオンとオフを試し、web.config ファイルに加えられた変更を確認します。

詳細情報:

ASP.NET 2.0 のプロバイダー モデルを使用すると、アプリケーションインストルメンテーションだけでなく、メンバーシップ、プロファイルなどの他の多くの用途でも独自のプロバイダーを作成できます。カスタム プロバイダーを記述してアプリケーション イベントをテキスト ファイルに記録する方法の詳細については、 こちらのリンクを参照してください。