Anyone who is a regular ASP.NET developer is likely familiar with the ASP.NET Page LifeCycle diagram that Kris van der Mast posted on his blog more then 3 years ago. It is indisputably the best reference when trying to determine where to insert your code in the life cycle of your pages. There is however a lack of clarity on where MasterPages fit into the picture. With a bit of logging and digging, here’s a diagram which illustrates clearly in which order MasterPage and Page events are fired. If you’re deriving a custom MasterPage or Page class for your site, the diagram also shows the relation between your class code and the automatically attached MasterPage and Page events.
If you’re building a site that contains nested applications, you may find yourself confused at what appears to be IIS completely disregarding your virtual directories. The behavior is by design. Although the applications will get isolated, the web.config settings from parent applications propagate to children applications. An easy fix is to simply wrap your web.config with the following to disable propagation :
<location path="." inheritInChildApplications="false"> <system.web> ... </system.web> </location>
Most sections can be wrapped at the exception of <configSections>, <runtime> and of course, the <configuration> root node.
Many developers seem to find it difficult to get their ASP.NET pages rendering in a valid XHTML Strict fashion. The solution is just a quick MSDN lookup away. Only two steps are required.
One, declare the proper XHTML Strict DOCTYPE :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Two, edit your Web.Config file and the following to the System.Web section :
ASP.NET will now adjust the HTML it outputs from controls and get rid of the infamous name attribute on the form tag.