15 Jun Making an ASP.NET 4.0 Website work with 3.5 Virtual Directories Under It
One might assume that a parent website application set to ASP.NET 4.0 in IIS 6 would have no issue running backward compatibility for its virtual directories (VirDirs) that are still written in ASP.NET 3.5 or even 2.0… But you’d be wrong.
Here’s an example structure:
- MyWebsite (.NET 4.0)
- MyInsetApp1 (.NET 3.5)
- MyInsetApp2 (.NET 3.5)
Which could create URLs like this:
(they appear to be on the same website, but actually run as separate distinct applications)
You actually have to jump through some hoops with the web.configs for both the parent website application and the child Virtual Directories.
If you allow the web.configs to remain as the defaults created by VisualStudio and try to run this scenario, you’ll get an error message about the application not being able to run under this version of .NET and/or various areas of the web.config already having been defined.
(sorry I failed to copy the actual error messages I saw at the time)
I did lots of searching online, and each article I found gave one of two possible things to try, and only until I combined both did I solve the issue.
Ultimately you have to both remove the references to versions in the web.config of all apps (at least the overlapping sections), and then also stop the child apps from inheriting the settings within the
node by modifying the parent’s web.config.
In the parent website application (running ASP.NET 4.0)
You’ll need to delete the “Version 126.96.36.199” from the <sectionGroup> node, seen here:
Then, also remove the “targetFramework” attribute of the <compilation> node. And wrap the <system.web> node with a <location> tag that has the “inheritInChildApplications” attribute set to false, like so:
In the child Virtual Directory applications (running ASP.NET 3.5 or lower)
All you have to do in these is remove the “Version 188.8.131.52” from the <sectionGroup> node. This is the same as shown above, only the one above is “184.108.40.206” and this one would be “220.127.116.11”. NOTE: “18.104.22.168” is used for version 3.5 as well, as the CLR between version 2.0 and 3.5 did not change.
After that, your nested applications should be back up and running.