Changing ASP.NET web.config inheritance when mixing versions of child applications
My blog and all the sites in and around it are a mix of .NET 2.0, 3.5 and 4. This blog engine is currently .NET 3.5 and runs at http://hanselman.com/blog, but the application at http://hanselman.com/ (the root) is .NET 4.
You can happily mix and match applications across .NET versions on a single IIS instance. You can see how mixed my system is in the screenshot at right there.
However, things got messy when I changed the parent / application to .NET 4, but kept the child /blog as .NET 3.5 (the 2.0 CLR). I got lots of errors like
- Unrecognized attribute ‘targetFramework’. Note that attribute names are case-sensitive. The targetFramework attribute was inherited from the root .NET 4 Web.config file in the Default Web Site root using ASP.NET configuration inheritance and confused the /blog .NET 2 application.
I didn't want to change the /blog applications' web.config. I just wanted to stop it from inheriting the settings from the parent application. Turns out you can wrap whole sections in a location tag, and then tell that scoped tag to prevent child applications from inheriting.
What you do is change the parent .NET 4 app's web.config to indicate its settings shouldn't flow down to the children, like the .NET 2/3.5 /blog app.
<location path="." inheritInChildApplications="false">
<system.web>
...your system.web stuff goes here
</system.web>
</location>
You can actually read about this in detail in the ASP.NET 4 "breaking changes" documentation. Of course YOU read those closely, don't you? ;)
I chose to change this settings for all of System.Web, but you could do it on a per-section basis if you preferred.
Hope this helps you!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Craig - Yes, I'm working on getting it added.
It is still possible to have a .net 2.0 root and have .net 4.0 applications beneath the root (think a Sharepoint 2007 instance with .net 4.0 mvc applications beneath it).
You have to do this however by all sorts of nasty messing around in the root web config and possibly (depending on what you are using) also using assembly redirection in the child.
We had to do this because there is no way to say for just one child to not inherit, you have to say "i'm not inheritable).
Microsoft totally screwed up here by making folder structure more important than "application" designation.
Also, each app pool should have it's own machine.config for that .NET version.
That would have been the proper way to handle all this. Everything else is just a slimy kludge on top of a bad design.
For example:
- Load IIS
- Click on your website
- Load .NET Error Pages
- Change the setting in here
- Look in your web.config to see what it's done!
In my case it creates a new system.web at the bottom. I've battled with this for over 5 years.
Is it possible to make main runs in .Net 2.0 Frame work and blog as .Net 4.0 Framework with out using sub web.config ?
I am a freasher frankly speaking
Can you reach Azure team and ask them why they don't let people deploy apps to Azure (ASP.NET Web Site with small SQL Server DB) for free? I find it weird that guys like AppHarbor can do it but MS can't. I think that could convince more people to pay for other Azure services.
But for websites like thisdeveloperslife.com, ratchetandthegeek.com and a dozen others I use SQL Compact Edition for free. It's worked great for almost a year.
Does that help?
Maybe 5$ isn't much but 60$ a year for app that is built just for fun is not sth I'm ready to pay.
The most interesting part - that application works in the local UAT environment (configured exactly the same as the production) and in one production server, on the second production server it gives an error about wrong configuration (even if the deployed code seems to be exactly the same on both instances. We've been fighting with this issue for some time - but no luck :( .
Honestly speaking - I don't want to introduce changes into root web.config = as new child application is not the only one hosted under same root and it somehow can affect other children (at least there's a chance).
Currently we're going to reinstall app from scratch on the broken server, and I'm willing to introduce changes only into child web.config. In case it's not going to help - I'm simply considering to move away from web application approach (under root item) and have it deployed as standalone web site (just to remove additional dependencies with parent).
Comments are closed.
<location path="." inheritInChildApplications="false">
<system.web />
</location>
in the parent web.config and not have unrecognised attribute explosions? If so, you rock!