Reflector fun with System.Web assembly

Earlier this week I gave an Advanced ASP.NET 2.0 for Class-A. The course takes a deep dive into the various services of ASP.NET 2.0. During the preparation for this course I took Reflector for a spin and checked the internals of System.Web.dll. I can really recommend doing so, if you want to find out a lot of the workings of the services. I’m talking about stuff that you do not find easily (or at all) with Google or in books.

Some examples:

  • When do the instrumentation heartbeat start?
    This happens on the initialization of the first request of a page in the website or application. Meaning that if your AppDomain is teared down, there will be no more heartbeat, and it will only resume when someone makes a request again.

private void FirstRequestInit(HttpContext context)

{

  // …

  this.InitializeHealthMonitoring();

  this.InitRequestQueue();

  this.InitTrace(context);

  HealthMonitoringManager.StartHealthMonitoringHeartbeat();

  //…

}

  • There is a DefaultAuthenticationModule class that gives you a HTTP module that does no authentication itself. It will let you handle the Authenticate event and roll your own authentication, without the need to create a custom authentication HttpModule class. BTW, this event exists on all authentication modules, and allows you to override the usual implementation for authentication. You can decide what the circumstances are when you would want to do so, but I can imagine that debugging could benefit from this.

Anyway, you also discover some very weird things inside of the implementation of System.Web. Here are the fun things I found out:

  1. Some programmer on the team has some spelling issues, a bad mouth or a problem with certain parts of the human body
    Check the resources of System.Web and find that there are a whole bunch of keys with a peculiar spelling
  2. It’s pretty hard to keep implicit and explicit resource binding apart
    When you combine both forms of binding in a sitemap, you will get the following error message:

    Using $resources clearly indicates explicit binding, and not implicit like the message wants you to believe. 
  3. Using concrete class specific knowledge in a base class
    The XmlSitemapProvider class derives from the base class StaticSitemapProvider. This class should be the base for all sitemap providers that have a static sitemap. When you look into the implementation of StaticSitemapProvider you will find references to resources of the XmlSitemapProvider in the AddNode method.

OK, not that bad all together, but it makes you wonder if refactorings and spell errors (variables named seperator) are ever fixed. Let me know if you found other cockups.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s