在具有4.0应用程序池的站点下运行的2.0应用程序池的子应用程序

Question

方案

我有一个使用ASP.Net 4.0构建的IIS站点应用程序，使用自己的app 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”属性。

我理解为什么，并找到了两个解决方案/解决方法，但我并不完全理解每个解决方案/解决方法的含义。

修复

1。将应用程序的应用程序池设置为v4.0。

2。将应用程序的应用程序池保留为v2.0，但更改父站点的web.config以中断<compilation>部分的继承：

<location path="." inheritInChildApplications="false">
    <system.web>
        <compilation targetFramework="4.0" debug="true" />
    </system.web>
</location>

问题（S）：

这些修复/解决方案究竟发生了什么？

在方案＃1中，4.0 CLR正在编译/运行2.0应用程序吗？假设是这样，CLR是否试图将其作为2.0应用程序运行（即向后兼容性）？或者它只是假设它是一个4.0 Web应用程序（似乎很危险）？

在方案＃2中，我知道我们已经阻止子应用程序看到targetFramework属性，但2.0 CLR是否真正编译/运行应用程序？如果是这样，是否需要在ASP.Net 4.0站点下安全运行ASP.Net 2.0应用程序？

Answer 1

我多次使用过场景＃2，从未遇到任何问题。所以是这就是在ASP.Net 4.0站点下安全运行ASP.Net 2.0应用程序所需的全部内容。

虽然没有人能回答你的两个应用程序肯定会以这种方式一起工作。可能最好做一个完整的系统测试，如果你发现任何特定的问题发布一个新的问题。