特定のセクションの継承を無視するように指示するために、web.configの特定の部分で<location path="." inheritInChildApplications="false">
を使用することはできません(「inheritInChildApplications属性が宣言されていません」などのエラーが発生するため、それがサポートされていないセクションでそれを)。
たとえば、<configSections>
の前または内部では使用できません。たとえば、<system.web>
タグをロケーションタグで囲むことができますが、<configSections>
での継承を停止する必要があるため、これを行う方法がわかりません。
サブアプリケーションは、親アプリケーションのWeb構成がツリーのIIS 7にあるのと同じ構成設定の一部を継承しています。 <clear/>
をconfigSecionタグに追加する方法はありません。タグを追加しようとすると無効になるためです。
そのセクションを無視するようにどのように伝えますか?
この非常に同じ質問がSOや他の多くのフォーラムで何度も尋ねられました。回答は多かれ少なかれ同じでした。configsectionで場所/クリア/削除を使用することはできません。
マイクロソフトは次のように彼らのスレッドにさえ答えました。
マイクロソフトが2009/07/23 17:40に投稿
<clear /> and <remove />
同じセクションハンドラーとセクショングループの異なる定義をマージしようとすることが困難なため、configSectionsとsectionGroupsには実装されませんでした。
このタイプの機能をVS 2010リリースに追加することを検討しましたが、2つの理由でこれに反対しました。
1つ目は、セクションハンドラーとセクショングループがbootstrap構成システムに使用されるためです。その結果、構成のブートストラップの途中でマージセマンティクスを許可するシステムは解決するのは重要な問題です。
2番目の理由は、通常、セクションハンドラーとセクショングループの定義が2つの異なる場所で作成されることです。最初の登録セットはルート構成ファイルにあり、次にadditiveアプリケーションレベルのweb.configの登録のセット。これは、開発者がハンドラー定義を変更したいというシナリオが有効ではないという意味ではありません。これは、可能性が低いシナリオにすぎません。 Connect経由で提案を送信していただきありがとうございます。
このSOスレッドを確認してください。この単純な状態は、競合するセクショングループの使用を回避します。
しかし、ナイアマンは以下を提案している、
サブフォルダーで同じセクションを別の方法で定義できるかどうかはわかりません。そのサブフォルダーをスタンドアロンの仮想アプリケーションにすることができます。その場合、親から設定を継承しません。このシナリオでは、独自のアプリプールでも実行されます。 InProc依存関係がない場合は、それもオプションです
これに対するこのstackoverflow回答のクレジット: "エントリはすでに追加されています"-2つの個別のアプリケーションプール
ここに含まれているので、文句を言わない...
C:\ Windows\System32\inetsrv\config\applicationHost.configを編集して追加します
enableConfigurationOverride="false"
親からweb.config設定を継承してはならない各アプリケーションプール。これは次のように私に現れました:
重複する「system.web.extensions/scripting/scriptResourceHandler」セクションが定義されています
.NET4アプリを(個別のアプリケーションやプールとしても).NET2親アプリの下で実行したい場合、これが唯一の実行可能なソリューションのようです。
このプロパティを含むapplicationHost.configのアプリケーションプールエントリの例:
<add name="MyApplicationPool" autoStart="true" managedRuntimeVersion="v4.0" enableConfigurationOverride="false">
<processModel identityType="ApplicationPoolIdentity" />
</add>
あなたができることは、そのフォルダーをアプリケーションにして、リバースプロキシを(IIS 7のURL書き換えモジュールを使用して)別の内部サイトに実行し、設定を完全に分離しておくことです。
たとえば、プロキシリダイレクトの1つは次のとおりです。ワイルドカード*を使用してパターンを照合し、URLを書き換えます http://127.0.0.1:8080/ {R:1}
正直に言うとひどい考え(私は物事を成し遂げるための汚い方法が嫌いです)は、IIS子アプリケーションの構成の白紙の状態を望んでいることを伝えることができるはずです。