Tech Ed Day 4 - Understanding ASP.NET Internals

Understanding ASP.NET Internals was perhaps the most technical session I've been to so far at Tech Ed, and seeing as it's now Thursday and I fly home tomorrow evening, probably the most technical I'll go to.

Rob Howard presented a session that was both fast paced and very in depth based on my current knowledge of ASP.NET. As a developer I'm mostly happy if the applications I'm creating work as they should, but knowing what's happening under the hood is useful on many occasions.

However, as I wouldn't call myself a Web Developer (I'm much happier coding Esendex's Windows Services, where I know what the inputs and outputs need to be), I nervously took my seat in a packed session room this afternoon.

First up was an introduction to Rick Strahl and Michele Leroux Bustamante, both of whom have blogs relating ASP.NET's internals. Rob's blog also contains links to all the slides and code samples used in the presentation, so head over there if you weren't able to get in the session. I don't know if they were turning people away at the door, but the room was definitely full.

The first point of note is that you can host the ASP.NET runtime in your own processes--now why would you want to do that? Well, if you need to write tests for your pages then hosting an environment that can act as a very controlled mock up of IIS can be very useful. The code to do it also didn't seem that onerous either.

Download the code samples and check out the MyHost.cs file in the Host directory and see for yourself.

Then we moved onto the differences between IIS 5.1 and IIS 6.0 and how they serve ASP.NET applications differently. Check out the slides to see the diagrams for yourselves. I don't have PowerPoint on my laptop, so I can't say exactly which slides to look at. Should be pretty obvious though from the headings.

Rob made a remark about SQL Server session state that could be useful to some of you out there. When using session state in the default way, ASP.NET will read and lock on the way in and write and unlock on the way out. You can optimise this to only do a read if you are not updating session state, or disable it totally if you are not using session state at all. Read this MSDN article on session state best practices for more information.

Did you know about the @OutputCache page directive? This can be used to dramatically speed up handling of pages as the page is placed in memory on the server rather than back on disk. Check out more details on ASP.NET caching here and here.

Finally we have the HttpContext.Items collection. Say you have a bunch of HttpModules and HttpHandlers loaded that use the same information. You can set this information in the first module/handler that is loaded and shove it into the Items collection. Then in subsequent handlers or modules you can check to see if the object you need is already there and use it, so you don't have to recreate it.

This can be handy if you're doing a lot of the same database hits each time through your modules or handlers. Rob calls this "per-request caching" as the Items collection (along with the HttpContext) gets dumped on completion of every request.

So, a fair bit of information there. I strongly recommend downloading the code samples and slides to see for yourself. Contained within them is a control called EventLogs.cs (in the TechEd2007/Controls directory) that will render a machine's Event Logs to the screen. Apparently there's a company selling something exactly like this for $200, so if you want one that's free, and comes with the source, go check it out.