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

Question

情境

我有一个使用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应用程序池运行。 这样做会导致服务器错误-无法访问父站点的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>

问题：

这些修复程序/解决方案实际上是怎么回事？

在方案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应用程序所需要的吗？

Answer 1

我已经多次使用方案2，但从未遇到任何问题。 因此， 是的，这就是在ASP.Net 4.0站点下安全运行ASP.Net 2.0应用程序所需要的全部。

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