Scenario
I have an IIS Site application built using ASP.Net 4.0, running with its own app v4.0 app pool. Hosted by this site is a child Application built using ASP.Net 2.0, with its own app pool.
<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>
My first thought is that the 2.0 Application should run using a v2.0 app pool. visiting the URL when doing so causes a server error -- it does not recognize the "targetFramework" attribute in the parent Site's web.config compilation settings.
I understand why, and have found two solutions/workarounds, but I do not fully understand the implications of each one.
Fixes
1. Set Application's app pool as v4.0
.
2. Leave the Application's app pool as v2.0
, but change the parent Site's web.config to break inheritance on the <compilation>
section:
<location path="." inheritInChildApplications="false">
<system.web>
<compilation targetFramework="4.0" debug="true" />
</system.web>
</location>
Question(s):
What's really going on with these fixes/solutions?
In scenario #1, is the 2.0 Application being compiled/run by the 4.0 CLR? Assuming so, is the CLR attempting to run it as a 2.0 app (i.e. backwards compatibility)? Or is it simply assuming it is a 4.0 web app (seems dangerous)?
In scenario #2, I know we have stopped the child app from seeing the targetFramework
attribute, but is the 2.0 CLR truly compiling/running the application? If so, is this all that is needed to safely run an ASP.Net 2.0 application under an ASP.Net 4.0 site?