You are currently browsing the tag archive for the ‘ASP.NET’ tag.
I learned something new over the last week which I not exactly sure of the benefit of. Probably because I still not entirely sure on how it is implemented.
It seems that in IIS7 that the default functionality is that the web.config in the root website is inherited to the child webs.
Of course I found this the hard way. I changed to a new web host and while setting up my base sites I wanted to try out a few new applications. I setup Umbraco under a sub-domain and played around with that for a while and remembered Orchard from MVConf. I setup a virtual directory, /orchard, and loaded up the site.
I kept receiving 500 errors when going to the site. There was a whole round of support emails around figuring out where the errors where steaming from. Once I found out I learned about the IIS7 inheritance.
For starters I want to list the ways I found to disable the inheritance and then move on to how this could be useful. (Man it’s always something)
<location path="." inheritInChildApplications="false"> <system.web> ... </system.web> </location>
There is also three examples in the IIS.NET bog: http://blogs.iis.net/steveschofield/archive/2009/09/19/control-web-config-inheritance-with-iis-7-asp-net-options.aspx
- You can set the enableConfigurationOverride attribute to false for an application pool
- allowSubDirConfig=false (as above)
- inhertInChildApplications property
I haven’t tried all of these yet. If you have leave a comment on how it well worked. It seems this functionality is enabled when the AppPool is set Integrated mode.
I just read one suggestion to use <clear /> what was inherited in certain sections.
Now for some reasoning on why this functionality was added
For now I just have this link from ASP.NET MSDN library. It starts out with:
“You can distribute ASP.NET configuration files throughout your application directories to configure ASP.NET applications in an inheritance hierarchy. This structure allows you to achieve the level of configuration detail that your applications require at the appropriate directory levels without affecting configuration settings at higher directory levels.”
I have some reading to do…
Reading an informative article on iis.net, Understanding Sites, Applications, and Virtual Directories on IIS 7
The only problem I have with the article is that there absolutely no details on any of the information provided. Yet it’s a good overview of what they have done in the new version.
Now here are the details I have been looking for: http://learn.iis.net/page.aspx/243/aspnet-integration-with-iis-7/
I ran in to an interesting issue yesterday. In an IIS 6 web server we have a website set to run ASP.NET 4.0. I was configuring a virtual directory to run under ASP.NET 2.0 to run ScrewTurn Wiki. Our standard config has the DefaultAppPool configured with ASP.NET 2.0 applications which don’t require their own pool. The wiki was running without issue. I decided to put the wiki in it’s own pool for various other reasons.
So I proceeded to configure a new application pool templated from DefaultAppPool. Once the new application pool was assigned to the virtual web I started noticing some strange behavior. Anytime I requested a URL which didn’t include a page name my get request would include the file eurl.axd. For ScrewTurn this means everytime you request the main url, it says it cant find the page named eurl, very annoying.
I wrestled for a while trying to figure out why this was happening. At first I didn’t realize it had to do with the new app pool. After a some googling time I cam across a Microsoft article of .NET 4 breaking changes which contained the issue I ran into. (Very strange, http://www.asp.net is down right now with an error screen…). To test this further I changed another running web application to this app pool (which was running under DefaultAppPool) and it did the same thing, looked for eurl.axd on the request.
The article can be found here: http://www.asp.net/learn/whitepapers/aspnet4/breaking-changes#0.1__Toc256770153 and explains why this is happening. In a nutshell it has to do with the website running ASP.NET 4.0 and virtual webs running ASP.NET 2.0.
What I find very strange about this bug is that as long as I use the DefaultAppPool I don’t have this issue (and yes, the website itself has it’s own app pool). I only experience the bug when a new app pool is created for the virtual web which is running ASP.NET 2.0.
keys: eurl, eurl.axd,