2011-09-12 3 views
0

私が取り組んでいるASP.NET Webアプリケーションは、複数のweb.configファイルを使用しています。 1つはWebルートフォルダに格納され、次に、独自のweb.configファイルを含むアプリケーションのWebルートの下にあるネストされたフォルダにある "admin"という別のプロジェクト(* .csproj)があります。 セカンダリweb.configファイルで、ASP.NETの設定(またはその他の設定)がUSED(またはNOT USED)になっていますか?私はTelerikのRad Controlをアップグレードし、いくつかの新機能を追加しています。ただし、これらのコントロールはメインWebアプリケーションには適用されません。それらはすべて管理プロジェクトページに適用されます。だから私はそれを助けることができる場合は、メイン/プライマリweb.configファイルに何かを追加したくない。セカンダリweb.configを使用しているときに、やりとりを共有することもできます。ASP.NET Webアプリケーションのセカンダリweb.configファイルではどのような設定が使用されていませんか?

答えて

1

web.configすべての設定ファイルと同じように、ファイルは基本的にhierachyレイアウトでマージされます。以下の点を考慮してください

machine.config (1) 
    -> web.config (2) 
     -> applicationHost.config (3) 
       -> web.config (4) 
        -> web.config (5) 

.NETで構成機構は、構成要素を上書き(またはロック)することを可能にする構成階層の様々な段階で、ここで:

  1. machine.configは、マシンレベルの設定であります - コンフィグレーションはすべて .NETアプリケーションに適用されます。
  2. ルートweb.configは、ASP.NETモジュール/ハンドラの大部分が設定されており、コンフィグレーションがすべての ASP.NETアプリケーションに適用される、マシンレベルのWebコンフィグレーションです。
  3. applicationHost.configはIIS7ルートWeb構成です。アプリケーションプールが統合モードで実行されている場合、モジュール/ハンドラー構成項目が使用されます。
  4. アプリケーションweb.configは、アプリケーションレベルのWeb構成です。ここでの設定はアプリケーションに適用され、すべての子フォルダ/仮想フォルダに適用されます。
  5. 仮想フォルダweb.configは、仮想フォルダレベルのWeb設定です。ここの設定は現在の仮想フォルダに適用され、すべての子フォルダ/仮想フォルダに適用されます。

クラシックパイプラインモードでIIS < 7、またはIIS7上で実行している場合は、applicationHost.configファイルがマージされた構成の一部として使用されていません。

.NETコンフィグレーションフレームワークは、コンフィグレーションをすべて上の階層にマージし、必要に応じてオーバーライドとロックされたコンフィグレーション要素に従います。

あなたの場合、IISアプリケーションの仮想フォルダレベルで構成を適用する必要があると思います。

0

両方のWeb.configが使用されます。ルートフォルダ内のWeb.configファイルは、その下のすべてに影響します。ルートフォルダのサブディレクトリにあるWeb.configは、その下のすべてに影響します。両方のWeb.configファイルに競合がある場合、アプリケーションはおそらく例外をスローします(たとえば、両方のWeb.configファイルに同じ値のアプリケーションキーを追加した場合など)。

Telerikコントロールがサブディレクトリにあるプロジェクトでのみ使用される場合は、そのサブディレクトリのルートではなくWeb.configファイルに変更を追加する必要があります。

関連する問題