IIS 7.0 の構成の詳細

  • [アーティクル]

公開日: 2007 年 11 月 22 日 (作業者: saad (英語))

更新日: 2009 年 9 月 9 日 (作業者: saad (英語))

はじめに

IIS 7.0 の構成システムは以前のバージョンの IIS とは大きく異なり、.NET Framework 構成システムの一部 (すべてではない) の概念に基づいて構築されています。 構成の対象範囲は Web サーバー プラットフォーム全体 (IIS、ASP.NET) に及び、まったく新しい IIS 7.0 管理 "スタック" のコアとして機能します。 このドキュメントでは、構成システムの設計およびアーキテクチャについて説明し、最低レベルのシステム、ネイティブ コード、エントリ ポイントへのプログラミング インターフェイスを紹介します。

この記事の内容:

  • 構成レベル

  • 設定の編成

  • 編成 <==> XML マッピング

  • スキーマ

  • スキーマ宣言の編成

  • <ConfigSections> での追加のスキーマ情報

  • ロック

  • ロック解除

  • まとめ

実行時に構成システムを実装する "可動部分" はほとんどありません。 構成システムは、クライアント アプリケーションでインプロセス実行されるライブラリとして実装され、ディスク上の永続的なストアを操作します。 このストアは、単純に、ファイル システム上のファイルまたはファイルのセットです。 ファイルの形式は XML です。 ユーザーは、手動でいつでもファイルを編集することも、変更をシステムで自動的に取得することもできます。 設定の保護、設定のバックアップ、設定の移動、新しい設定によるシステムの拡張などの標準的な操作を実行するために、独自のモデルは使用されていません。 システムでは、ファイル システムを利用することによって、Web アプリケーションやサービスの構成の展開などのタスクを簡素化しています。

注: 以前のバージョンの IIS とは異なり、一元化された構成サービスはありません。 これによって、ストアから大きなチャンクのデータを読み込む場合、特に起動時に、プロセス間通信やバッファー コピーの必要がないので、パフォーマンスが大きく向上します。

IIS をインストールした後、既定の状態では、構成は次のようなものによって使用されます。

  • WAS (Windows アクティブ化サービス): アプリケーション プール、サイト、その他の設定のグローバルな既定値を読み込みます。
  • Web サーバー コアとワーカー プロセスのモジュール: 要求を処理するためにアクティブ化されると、その動作を制御する構成設定が読み込まれます。
  • WMI プロバイダー: IIS 7.0 スクリプト インターフェイス プロバイダーは、内部で構成システムを使用して設定を取得および設定します。
  • AppCmd.exe: IIS 7.0 コマンド ライン ツールは、内部で構成システムを使用して設定を取得および設定します。
  • UI: IIS 7.0 管理フレームワークは、内部で構成システムを使用して設定を取得および設定します。
  • レガシー: ABO、ADSI、および IIS 6.0 WMI プロバイダーなどのインターフェイスを使用するアプリケーションやスクリプトは、レガシー ABO API およびモデルを新しい構成モデルにマップするコンポーネントを通じて、間接的に構成システムを使用します。 この状態は、常に、新しい構成システムに保存されます。

構成設定へのアクセスを可能にするインターフェイスはいくつかあります。

インターフェイス 

アクセス先 

テキスト エディターを使用した手動でのファイルの編集、またはスクリプトによる編集。

すべての構成ファイル (ファイルの ACL で許可されている場合)。

ネイティブ コードおよびマネージ コードの構成 API。

すべての構成ファイル (ファイルの ACL で許可されている場合)。

IIS 7.0 WMI スクリプト プロバイダー、UI、appcmd.exe tool など、構成システム上のさらに高いレベルの抽象化。

すべての構成ファイル (ファイルの ACL および UI の委任ポリシーで許可されている場合)。

ABO、ADSI、IIS 6.0 WMI プロバイダーなどのレガシー IIS インターフェイス

ルート IIS 構成ファイルのみ、およびレガシー (IIS 6.0) 設定のみ。 .NET Framework 設定および新しい IIS 7.0 設定は、これらのインターフェイスには表示されません。

System.Configuration などのレガシー .NET Framework インターフェイス。

machine.config および web.config ファイルの .NET Framework 2.0 構成設定のみ。  

構成レベル

URL 名前空間の各レベルには、構成を関連付けることができます。 特定のレベルの構成は、子のレベルで特に変更されない限り、子のレベルに継承されます。 URL ごとの構成を簡単に実現するには、仮想パスにマップされる物理ファイル システムのフォルダーで web.config ファイルを使用します。 ルート レベル (コンピューター レベル) では、構成セクション グループに応じて、個別のファイルを使用する必要があります。構成セクション グループについては、後で説明します。ここでは、構成を格納する XML 要素の名前だと考えてください。

セクション グループ 

説明 

ルート ファイル 

system.applicationHost

Windows アクティブ化システム: プロセス モデル  

system32\inetsrv\config\applicationhost.config

system.webServer

IIS: Web サーバー  

system32\inetsrv\config\applicationhost.config

system.web

ASP.NET  

Windows\microsoft.net\framework\v2.0.50727\config\web.config  

system.*

その他 .NET Framework  

Windows\microsoft.net\framework\v2.0.50727\config\machine.config  

[Microsoft other]

Microsoft のその他  

Windows\microsoft.net\framework\v2.0.50727\config\machine.config

[custom]

3サード パーティ

machine.config、ルートの web.config、applicationHost.config のいずれか (サード パーティ/ユーザーによって異なる)

  

web.config ファイルが適切ではない場合や、使用できない場合があります。 以下に例を示します。

  • セキュリティ: コンピューター管理者は、サーバー上のあらゆる場所で構成が管理できれば便利であると考えることがよくあります。 web.config がコンテンツ ディレクトリにある場合、これらのディレクトリに対して書き込みアクセス権を持っているサイトレベルの管理者 (またはアプリケーション開発者) は、web.config ファイルを xcopy を実行 (または FTP 転送、その他の方法で変更) することができ、望ましいポリシーに違反します。
  • リモートでの変更の通知: コンテンツ ディレクトリがリモートの (UNC) 共有にある場合、web.config を使用すると、パフォーマンス、スケーラビリティ、その他の問題が発生します。 たとえば、一部の Windows 以外のバックエンド ファイル システムでは、Windows で想定されている方法でファイル変更通知がサポートされていない場合があります。 別の例として、ファイルの変更を監視するために、システムが多数のリモート ディレクトリへの接続を開いたままにして、サーバー上のリソースを過剰に使用している場合、パフォーマンスの問題が発生します。
  • 一元管理: 構成の管理、検出、およびトラブルシューティングを容易にするために、コンピューター管理者は、ルート レベルの 1 つのファイルに、階層のすべてのレベルの構成を格納しようとする場合があります。 実際には、グローバル レベルでは 3 つのファイルがあります。.NET Framework 構成設定用の machine.config とルートの web.config 、および IIS 構成設定用の applicationHost.config です。 これは、単に階層の各レベルでそれぞれの web.config ファイルを持つことに比べると、ずっと控えめです。
  • 共有された構成: 複数の仮想パスで同じ物理フォルダーを指している場合、そのフォルダーにある同じ web.config が共有されます。 当然、この web.config ファイルを使用して、異なるパス用の異なる構成を指定することはできません。
  • ファイル固有の構成: Web.config ファイルはフォルダー全体、つまりそのフォルダー内のすべてのファイルに適用されます。 特定のファイル用に異なる構成を指定するには、別の方法を使用する必要があります。

構成階層のあちこちに web.config ファイルを置く代わりに location タグを使用できます。これについては、次に説明します。

location タグ

location タグは、仮想パスにマップされるフォルダーに web.config ファイルを置く代わりに、パス固有の構成を指定するために使用されます。 パスの location タグは、構成階層の親レベルで設定され、その親レベルにあると見なされます。 このことは、ロックのセマンティックスや、どのレベルでどのセクションを指定できるかなどで重要になります。

location タグの主要な属性は "path" です。 次の値を指定できます。

  • "." (または ""): 現在のレベルを意味します。 一般的な場所のパスはグローバル レベルで設定されるので、"." はグローバル レベルを意味します。ただし、構成ファイル階層のどこででも設定できます。 これは、"path" が設定されていない場合の既定値でもあります。
  • "sitename": 特定のサイトのルート アプリケーション。
  • "sitename/application": 特定のサイトの特定のアプリケーション。
  • "sitename/application/vdir": 特定のサイトの特定のアプリケーションの特定の仮想ディレクトリ。
  • "sitename/application/vdir/physicaldir: 特定の物理ディレクトリ。 このパスは、"sitename/app/vdir/p1/p2/p3" の形式で、より複雑な場合もあります。
  • "sitename/application/vdir/file.ext": 特定のファイル。 このパスは、"sitename/app/vdir/p1/p2/file.ext" の形式で、より複雑な場合もあります。また、"sitename/app/file.ext" や "sitename/file.ext" の形式で、より簡潔な場合もあります。

1 つの構成ファイルで複数の location タグを使用することはできますが、(異なるセクションを参照していない限り) 同じパスを参照することはできません。 ただし、各 location タグが別の location タグの子のパスを参照している場合のように、子のパスを参照することはできます。 location タグの順序は、構成システムにとっては重要ではありませんが、人にとってはファイルの読みやすさの面で重要です。

<location path="."> 
  <system.webServer> 
    <defaultDocument enabled="false"/> 
  </system.webServer> 
</location>

<location path="MySite"> 
  <system.webServer> 
    <defaultDocument enabled="true"/> 
  </system.webServer> 
</location> 

<location path="MySite/YourApp/images"> 
  <system.webServer> 
    <defaultDocument enabled="false"/> 
  </system.webServer> 
</location>

設定の編成

構成ファイル内で、設定は "セクション" と呼ばれる単位に基づいて、構造化された形式でまとめられています。 構成セクションは論理的に関連する設定のグループで、ひとまとまりとして展開したり、システムから登録解除したりすることができ、通常は 1 つのサーバー モジュールで利用されます。

つまり、ワーカー プロセスで実行されるほぼすべてのランタイム モジュールには、対応する構成セクションがあります。 構成セクションは拡張の単位でもあります。新しい設定を構成スキーマに追加するには、構成スキーマに 1 つまたは複数のセクションを追加します。

セクションを入れ子にすることはできません。 アーキテクチャの面では、セクションは (多くの場合) 互いに独立しており、相互に参照することはできません。

セキュリティはさらに "セクション グループ" と呼ばれる論理的に関連するコレクションとしてグループ化されます。 セクション グループは、展開、登録、またはその他の実質的な操作 (ロックや暗号化など) の単位ではありません。 セクション グループには設定は含まれません。 セキュリティ グループの目的は、設定の編成をさらに構造化し、構成セクションが長いフラットなリストにならないようにすることです。

セクション グループは設定の階層を構築するために使用されるので、グループ間には親子の関係があります。 つまり、セクション グループは入れ子にすることができます。 あるセクションは常に 1 つのセクション グループにのみ属し、セクションに他のセクション (またはセクション グループ) を含めることはできません。 セクション グループは親セクション グループに属している場合があり、子セクション グループを含んでいる場合もあります。 セクション グループは通常、複数のセクションを含んでいます。セクションを含んでいなければ、セクション グループを作成する理由がないからです (ただし、ユーザーは、何らかの理由で、セクションを 1 つだけ含む独自のセクション グループを作成することによってスキーマを拡張できます)。

セクションとセクション グループの例を以下に示します。

<!-- section group for web server configuration -->

<system.webServer>
  <!-- section group for web server security configuration -->
  <security>
    <!-- section group for web server authentication configuration -->
    <authentication>
      <!-- three sections for authentication -->
      <basicAuthentcation ... />
      <windowsAutnentication ... />
      <anonymousAuthentication ... />
    </authentication>
  </security>
</system.webServer>

各セクションには名前があります。 短い名前はセクション自体の名前で、長い名前はそのセクションが含まれるすべてのセクション グループの完全な名前です。 たとえば、"windowsAuthentication" の完全な名前は "system.webServer/security/authentication/windowsAuthentication" です。 このような階層化された構造によって、将来、名前が同じでも、異なるセクション グループに属するセクション (およびセクション グループ) を作成できます。

編成 <==> XML マッピング

構成の永続的な保存形式は XML です。したがって、構成の編成単位と XML の用語の対応を理解しておくと便利です。 セクション グループおよびセクションは XML 要素です。 セクション内では、設定は XML の用語に従ったより小さい単位にまとめられています。

構成単位 

XML の用語 

説明 

構成要素

XML 要素 

他の子単位を含みます。値を持ちません。 

構成コレクション

XML 要素 

要素のプライベート ケースです。add/remove/clear の形式で要素のグループを含みます。

構成プロパティ

XML 属性 

値のみをを含みます。子単位を含みません。 

applicationHost.config の例を以下に示します。

<!-- "windowsAuthentcation" is a configuration section (XML element). -->
<!-- "enabled" is a configuration property (XML attribute).           -->
<windowsAuthentication enabled="true">
  <!-- "providers" is a configuration collection (XML element). -->
  <providers>
    <!-- Two configuration elements (XML elements).           -->
    <!-- "add" is the collection directive.                   -->
    <!-- "value" is a configuration property (XML attribute). -->
    <add value="Negotiate"/>
    <add value=""NTLM/>
  </providers>
</windowsAuthentication>

スキーマ

構成システムは、そのコアにある宣言型スキーマによって駆動されます。 これは、たとえば、IIS 6.0 の場合とは異なります。IIS 6.0 では、実際のスキーマはハードコーディングされており、ABO によって使用されません。また、ADSI プロバイダー (ABO 上の上位レベルのインターフェイス) には、ユーザーが拡張できる独自のスキーマがあります。 また、.NET Framework 2.0 のアーキテクチャとも大きく異なります。.NET Framework 2.0 では、設定の "スキーマ" は、多くの場合、それぞれのセクションを処理するためのロジックを実装する個々のクラスにコーディングされていました (これらのクラスは "セクション ハンドラー" と呼ばれていました)。 また、宣言型スキーマは、システムの拡張が、コードではなく、宣言をシステムに追加する作業であることも意味します (これもまた、.NET Framework のアプローチとは異なります)。

構成スキーマは複数のファイルにまたがり、system32\inetsrv\config\schema\ という既知の場所に保存されます。 既定では、コンピューター管理者だけがこのフォルダーにアクセスできます。 ユーザーやサード パーティでは、カスタム セクションのスキーマ ファイルをこのディレクトリにコピーすることによって、スキーマ ファイルを追加できます。 構成システムは、構成の呼び出し元のプロセスで、起動時に自動的にスキーマ ファイルを選択します。 既に構成システムが実行されている場合は、スキーマ ファイル (新しいファイル) への変更は選択されません。

このディレクトリにインストールされている IIS やその他のスキーマ ファイルを編集しないでください。エラーが発生して、スキーマが壊れたり、サーバーを起動できなくなったりする可能性があります。

注: 従来のファイル アクセス API および XML 解析/編集以外に、スキーマ ファイルを取得および設定できる上位レベルのプログラム インターフェイスはありません。 スキーマ ファイルを変更する前に、常にスキーマ フォルダーなどの機密性の高い情報をバックアップすることをお勧めします。

3 つのファイルによって、Web サーバー プラットフォームの統一されたスキーマが構成されます。

  • IIS_schema.xml: セクション グループ内の Windows アクティブ化システムおよび IIS Web サーバー設定に対応します。
  • ASPNET_schema.xml: セクション グループ内の ASP.NET 設定に対応します。
  • FX_schema.xml: さまざまなセクション グループ内のその他の .NET Framework 設定に対応します。

スキーマ宣言の編成

スキーマ ファイル内の編成は、セクションの単位に基づいています。 セクションは、上位のセクション グループを含む完全な名前によって定義されます。 セクション グループは、それ自体は定義されず、階層構造を示すセクション名の一部として使用されます。 各セクションのスキーマ宣言によって、セクションの名前、種類、および既定値が指定されます。 また、サブ要素、コレクション、プロパティなど、セクションないの構造も指定されます。

ここでは、説明のために XML コメントによる注釈付きの例を紹介します。「ApplicationHost.config の紹介」ドキュメントを参照してスキーマ システムの仕組みを理解し、各 IIS セクションのスキーマを検討することをお勧めします。

例:

<!-- The XML element name for defining a section schema is "sectionSchema" -->
<!-- It contains the full name of the section -->
<sectionSchema name="system.webServer/defaultDocument">
  <!-- A property schema is defined using an "attribute" XML element -->
  <attribute name="enabled" type="bool" defaultValue="true" />
  <!-- A sub-element schema is defined using an "element" XML element -->
  <!-- In this case, it is also a collection -->
  <element name="files">
    <!-- This collections uses the traditional "add", "remove", "clear" ->
    <!-- for the directive names, and supports all of them; other       -->
    <!-- collections may use different names, defined here, and support -->
    <!-- only some of the directives. Note the "prepend" behavior when  -->
    <!-- adding elements; most collections use "append"                 -->
    <collection addElement="add" clearElement="clear" removeElement="remove" mergeAppend="false">
       <!-- This defines the collection element schema; in this case, it -->
      <!-- has one attribute only: "name", e.g. <add name="file1.aspx"> -->
      <!-- The value for "name" is of type "string" and it serves as    -->
      <!-- the collection key, therefore needs to be unique             -->
      <attribute name="value" type="string" isUniqueKey="true"/>
    </collection>
  </element>
</sectionSchema>

<ConfigSections> での追加のスキーマ情報

必要なすべてのスキーマ情報がスキーマ XML ファイルにあるわけではありません。 一部のスキーマ情報は、構成ファイル自体の <ConfigSections> と呼ばれる特別なセクションにあります。 これは、.NET Framework の構成システムと一貫性があります。 既定では、<ConfigSections> は machine.config と applicationHost.config に存在しますが、ユーザーはこのセクションを web.config ファイルに追加してカスタム セクションを定義できます。 これらのセクションは、名前空間のそのレベルとその下位レベル用に定義されます。

注: ユーザーおよびサード パーティは、inetsrv\config\schema\ フォルダー、machine.config および applicationHost.config のいずれにある場合でも、ビルトイン セクションのスキーマ情報を変更しないでください。 この操作を行うと、これらのセクションの動作が不適切な動作になる場合があります。

その内容は、システムに "登録" されているセクションの一覧です (セクションの登録ポイント)。 また、セクション グループの階層も定義します。 ただし、セクション内のプロパティ (または要素) は定義されません。 セクションについては、いくつかの追加のメタデータが定義されます。

  • Type: 必須の属性。 これは、マネージ コード セクション ハンドラーの型です。.NET Framework 構成システムがセクションにアクセスするコンテキストにおいてのみ使用されます (System.Configuration クラス)。 厳密な型の定義で、アセンブリ名、バージョン、カルチャ、およびキーを含みます。
  • OverrideModeDefault: 省略可能な属性。 存在しない場合、既定値は "Allow" です。 これは、セクションの既定のロックダウン状態で、定義されているレベルまでロックダウンされるか、または構成階層の下位レベルで上書きできるかを示します。 "Deny" の場合、下位の web.config ファイルでこの設定を上書きすることはできません (つまり、このレベルまでロックダウンされます)。 IIS Web サーバーの多くのセクションはロックダウンされますが、すべてではありません。 .NET Framework のセクションの多くは、アプリケーション レベルの設定と見なされるため、ロックダウンされません。 この値が "Allow" である場合、下位レベルで設定が上書きされる可能性があります。
  • AllowDefinition: 省略可能な属性。 存在しない場合、既定値は "Everywhere" です。 これは、セクションを設定できる階層のレベルです。 "MachineOnly" である場合は、applicationHost.config または machine.config でのみ設定できます。 "MachineToRootWeb" の場合は、上記の "MachineOnly" 用に定義されているファイル、または .NET Framework 構成フォルダー内のルート web.config ファイルで設定できます (この値は .NET Framework のセクションについてのみ意味があります)。 "MachineToApplication" の場合は、上記の "MachineToRootWeb" 用に定義されているファイル、またはアプリケーションのルート フォルダーの web.config ファイルで設定できます。 "Everywhere" の場合は、アプリケーションのルートにない仮想ディレクトリにマップされたフォルダーや、その下位の物理ディレクトリなど、任意の場所にある構成ファイルで設定できます。

applicationHost.config の単純化したスニペットを以下に示します。

<configSections>
  <sectionGroup name="system.applicationHost" type="">
    <section name="applicationPools" type="" allowDefinition="MachineOnly" overrideModeDefault="Deny" />
    <section name="customMetadata" type="" allowDefinition="MachineOnly" overrideModeDefault="Deny" />
    <section name="listenerAdapters" type="" allowDefinition="MachineOnly" overrideModeDefault="Deny" />
    <section name="log" type="" allowDefinition="MachineOnly" overrideModeDefault="Deny" />
    <section name="sites" type="" allowDefinition="MachineOnly" overrideModeDefault="Deny" />
    <section name="webLimits" type="" allowDefinition="MachineOnly" overrideModeDefault="Deny" />
  </sectionGroup>
  <sectionGroup name="system.webServer" type="">
    <section name="asp" type="" overrideModeDefault="Deny" />
    <section name="defaultDocument" type="" overrideModeDefault="Allow" />
    <sectionGroup name="security" type="">
      <section name="access" type="" overrideModeDefault="Deny" />
      <section name="applicationDependencies" type="" overrideModeDefault="Deny" />
      <sectionGroup name="authentication" type="">
        <section name="anonymousAuthentication" type="" overrideModeDefault="Deny" />
      </sectionGroup>
    </sectionGroup>
  </sectionGroup>
</configSections>

ロック

location タグは、セクション全体のロックまたはロック解除によく使用されます。 セクション内の要素や属性のより細かいロックも、構成システムでサポートされていますが、location タグと直接的な関係はありません。

ロック解除は、ロックが定義されたレベルでのみ実行できます。 つまり、親レベルでロックされた内容を構成レベルでロック解除することはできません。 たとえば、次のセクションは既定でロックされていないので、applicationHost.config の location タグは特定の 2 つのサイトをロックダウンします。

<!-- lock down defaultDocument for MySite -->
<location path="MySite" overrideMode="Deny">
  <system.webServer>
    <defaultDocument/>
  </system.webServer>
</location>
  <!-- specify a value for defaultDocument.enabled and lock it for YourSite -->
<location path="YourSite" overrideMode="Deny">
  <system.webServer>
    <defaultDocument enabled="true">
      <files>
        <clear/>
        <add value="default.aspx"/>
      </files>
    </defaultDocument>
  </system.webServer>
</location>

前の例では、最初の location タグは、MySite のセクションのみを、定義済みの値と共にロックダウンします。 2 番目の location タグでは、(セクションを有効にし、files コレクションをクリアして 1 つの要素を追加することによって) 値を変更し、YourSite のセクションもロックダウンしています。 これは、YourSite レベル (web.config) で、既定のドキュメント機能が常に有効になっており、無効にすることはできず、提供される既定のドキュメントは default.aspx のみであること意味します。

前の例を少し変更すると、applicationHost.config だけではなく、下位レベルの web.config ファイルでも設定できます。 構成階層のあらゆるレベルで構成をロックできます (その下位のパスの場合。異なるパスの値を反映するために、例を少し変更する必要があるのはこのためです)。

同じセクションの location タグは、web.config ファイルと同様に、階層の複数のレベルにまたがることができます。 タグは継承規則に従って評価されます。 ここでは、web.config ファイルを基準として、階層の下位にある location タグがどのように評価されるかを具体的には指定しません。これは、人が明確な継承の階層やロックされた構成を作成しようとしたときに、アルゴリズムがわかりにくい場合があるからです。 このような理由から、location タグは、単に web.config ファイルを使用するよりも、わかりにくいまたは高度であると受け取られることがあります。 しかし、「アーキテクチャ」で述べたように、状況によって location タグを使用することには正当な理由があります。

前の例では、overrideMode 属性を使用してロックが行われています。 値は次のとおりです。

  • "Allow": location タグで指定したセクションをロック解除します。
  • "Deny": location タグで指定したセクションをロックします。
  • "Inherit": これは何も指定されていない場合の既定値です。 構成システムは、overrideModeDefault のセクション スキーマ定義まで、継承階層をたどって overrideMode の親の定義を見つけることによって、location タグで指定されたセクションのロックダウン状態を評価します。 値はスキーマ情報で指定されているか、既定値 "Allow" が使用されるので、最終的には overrideModeDefault 値によって解決されます。

システムは、location タグでセクションをロックするためのレガシー属性である allowOverride もサポートしています。 この属性は、overrideMode 以前に、.NET Framework 構成システムで使用されていました。 この属性は、次のように overrideMode のセマンティックスにマップされます。

allowOverride の値 

overrideMode の対応する値 

説明 

true 

Allow 

指定されたセクションをロック解除する 

false 

Deny 

指定されたセクションをロックする

[設定なし] 

Inherit 

継承階層をたどることによって解決する 

allowOverride モデルには、ここでは説明していませんが、いくつかの制限と複雑な点があります。 したがって、新しいモデルである overrideMode をお勧めします。

location タグで allowOverride と overrideMode の両方を指定することはできません。 これは無効な構成であると見なされ、実行時に適切なエラーが出力されて失敗します。

ロック解除

この例では、セクションをロック解除する方法を示します。 このセクションは applicationHost.config レベルでロックされているので、このレベルでのみロック解除できます。

<location overrideMode="Allow">
  <system.webServer>
    <modules/>
  </system.webServer>
</location>

特定のパスについてのみセクションをロック解除し、他のすべてのパスについてはロックしたままにしておくと便利な場合があります。 次の例では、前の例を基にして、特定の 2 つのサイトについてのみセクションをロック解除する方法を示します。他のすべてのサイトについては、ロックされたままです。

<location path="TrustedSiteOne" overrideMode="Allow">
  <system.webServer>
    <modules/>
  </system.webServer>
</location>
 <location path="TrustedSiteTwo" overrideMode="Allow"><span style="font-family:Calibri; font-size:11pt">
   <system.webServer>
    <modules/>
  </system.webServer>
</location>

ロック解除する必要がある各 "例外" パスについて、別の location タグが必要です。

ロックとロック解除が競合する場合に、混乱が生じる可能性があります。 次のような例を考えてみます。

<!-- in applicationHost.config: -->
<location path="MySite/shopping" overrideMode="Allow">
  <system.webServer>
    <modules/>
  </system.webServer>
</location>
<!-- in web.config at MySite root: -->
<location overrideMode="Deny">
  <system.webServer>
    <modules/>
  </system.webServer>
</location>

applicationHost.config レベル (MySite/shopping のセクションをロック解除する) と、MySite のルートにある web.config (サイトのセクションをロックする) との間で、競合が発生しています。 このような状況は、階層のレベルによって、構成を管理するユーザーが異なる場合に発生する可能性があります。 この場合、構成システムはこれを無効な構成と見なし、適切なエラーが出力されます。

まとめ

このドキュメントでは、IIS 7.0 構成システムの設計およびアーキテクチャの概要を示しました。 構成レベルの階層および分散 web.config ファイルを使用して、構成設定の管理の委任を実現する方法について説明しました。IIS の構成システムと .NET Framework の構成システムの統合ポイントについて、制限事項も含めて示しました。また、タグの概念およびどのような状況でタグが構成ファイルよりも適しているかについても説明しました。さらに、セクション レベルでの基本的な構成のロックも紹介しました。 セクション内での細かいロックを含め、構成のロックの詳細については、「IIS 7.0 構成でロックを使用する方法」を参照してください。

また、このドキュメントでは、構成ファイル内の設定の編成を示し、セクション、セクション グループ、要素、属性、コレクション、列挙、およびフラグの概念について説明しました。

最後に、スキーマ システムとその仕組みについて説明しました。これは、カスタム設定を使用してシステムを拡張する場合に役立ちます。 カスタム構成設定をシステムに追加し、カスタム構成設定を使用するコードを生成する手順の詳細については、「構成を拡張する方法」を参照してください。

関連コンテンツ

記事