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.
It didn’t take long for the entire world to learn about Microsoft’s submittable of 20,000 lines of code for the Linux driver base. As a surprise reaction to both sides of the camp, Linus Torvalds responded in favor of Microsoft’s move. I have a feeling that the most memorable portion of his response will become this little snippet :
I may make jokes about Microsoft at times, but at the same time, I think the Microsoft hatred is a disease. I believe in open development, and that very much involves not just making the source open, but also not shutting other people and companies out.