シナリオ
ASP.Net 4.0 を使用して構築された IIS サイト アプリケーションがあり、独自のアプリ v4.0 アプリ プールで実行されています。このサイトでホストされているのは、独自のアプリ プールを備えた ASP.Net 2.0 を使用して構築された子アプリケーションです。
<site name="Intranet" id="1" serverAutoStart="true">
<application path="/" applicationPool="Site-Intranet">
<virtualDirectory path="/" physicalPath="D:\sites\intranet" />
</application>
<application path="/ChildApp" applicationPool="App-ChildApp">
<virtualDirectory path="/" physicalPath="D:\apps\childapp" />
</application>
</site>
私の最初の考えは、2.0 アプリケーションは v2.0 アプリ プールを使用して実行する必要があるということです。URL にアクセスすると、サーバー エラーが発生します。親サイトの web.config コンパイル設定の「targetFramework」属性が認識されません。
私はその理由を理解しており、2 つの解決策/回避策を見つけましたが、それぞれの意味を完全には理解していません。
修正
1. アプリケーションのアプリケーション プールを として設定しますv4.0。
2. アプリケーションのアプリ プールは のままにしますv2.0が、親サイトの web.config を変更して<compilation>セクションの継承を解除します。
<location path="." inheritInChildApplications="false">
<system.web>
<compilation targetFramework="4.0" debug="true" />
</system.web>
</location>
質問:
これらの修正/ソリューションで実際に何が起こっているのですか?
シナリオ 1 では、2.0 アプリケーションは 4.0 CLR によってコンパイル/実行されていますか? そう仮定すると、CLR はそれを 2.0 アプリとして実行しようとしていますか (つまり、後方互換性)? それとも、4.0 の Web アプリであると単純に想定しているのでしょうか (危険なようです)。
シナリオ 2 では、子アプリが属性を認識しないようにしたことはわかっていtargetFrameworkますが、2.0 CLR は本当にアプリケーションをコンパイル/実行しているのでしょうか? もしそうなら、ASP.Net 4.0 サイトで ASP.Net 2.0 アプリケーションを安全に実行するために必要なのはこれだけですか?