(How)
C^# You Are - 27 May 2007

This week's questions revolve around ASP.NET.

1. How would you go about tracking per-session data centrally in an ASP.NET?  Answer

   The preferred approach is to use a base class and implement the logic in the base class.  This works well in all cases.  In the base class you can use the OnInit or OnLoad methods to do any initialization across all pages.  More importantly however is the fact that all the contextual information is available at this point including session and a user's profile (if authentication is not used).

   An alternative approach is to use one of the global configuration class's event handlers.  Unfortunately it is important to understand when the various objects available through the HTTP context are created.  Since the application object ultimately creates the HTTP context events are raised throughout the creation process.  In general session and page-level context information is not available for general use except in a few special cases.  Session itself is not created until AcquireRequestState is called so Session is only available from this event onward.

2. When is Session_(On)End called?  Answer

   Ultimately this event (in the global configuration class) will be called when session ends.  However session end is a relative term since it depends on the session provider.  In general you should not rely on receiving this event.  In the case of inproc state (the most common) it will be raised when the session times out.  However the other session state providers will not cause this event to be raised.  Furthermore if the ASP.NET process is prematurely terminated the event also will not be raised.

   Therefore, in general, you should not rely on this event for anything.  Some applications try to use this event for tracking login state of users but this is unreliable.

3. The page life-cycle is critical to understanding ASP.NET pages and controls.  What is the basic life-cycle of a page?  Answer

   Ctor - The page constructor is called.  It does basic initialization but server controls have not been created yet.

   PreInit (new to v2) - The page instance is created.  Server controls are created.  Some basic properties of the page are set.  Overridable theme properties are applied to controls at this point.  Any attributes defined in the ASPX page are pushed to the controls at this phase. 

   Init - The page controls are initialized.  However at this point any postback data has not yet been applied.  Any control properties can be overridden at this point. For themes that override any existing settings they are applied here.  This is a good place to do any initialization that might prevent the page from displaying such as security checks or whatnot.

   PreLoad - The page is being loaded.  This is the last event to be raised before postback data is applied.

   Load - The page is loaded.  Postback data has been applied and view state is restored.  This is the most common event handled.  Any data that is needed for rendering is generally loaded at this time.

   PreRender - The page is preparing to render.  Any pre-rendering steps should occur here such as the creation of any dynamic controls that will ultimately be rendered.  This event is almost exclusively handled in server controls only.  It is the last time a control can make any persistent changes before rendering.

   SaveStateComplete - This is important.  This event is raised AFTER view state is saved.  Any property changes made after this point will be lost after rendering.  They will not be persisted.

   Render - The page is rendered.  Again this event is normally only used in server controls.  Server controls render there content at this point.

   Unload - The page is finished and preparing to be unloaded.  Any cleanup needed from the load process should be done here.

4. What is the difference between an HttpModule and an HttpHandler?  Answer

   The most fundamental difference is in what they do.  An HttpHandler is responsible for taking a request from a browser and returning some result to the browser.  Ultimately every web page is an HttpHandler.  An HttpModule on the other hand is used to manipulate and analyze requests.  Modules are generally used for things like security, encryption or performance analysis.  For example you could create a module that tracks visits to your site so you know where you can optimize your code better or perhaps what pages to cache more aggressively.

5. What is the difference between a server control and an HTML control?  Answer

   You will find, in ASP.NET, references to server controls and HTML controls.  In general a server control is a custom ASP.NET class that provides functionality consistent with standard HTML elements like a text box or a button.  These controls are normally rendered through the standard HTML element but are often given additional functionality and properties to make them easier to work with.

   An HTML control, on the other hand, is a client-side only control that is defined directly in the ASPX page.  ASP.NET does not have access to these controls so you can not programmatically access them. In fact the ASP.NET parser (to date) will skip over HTML controls and simply send the data directly to the output stream.

   For completenes an HtmlControl is a server control that mimics the existing HTML elements.  These server controls are provided primarily as a catch all for HTML elements that are not directly supported in ASP.NET (such as HtmlGeneric) or as simplified controls when programmatic access is needed but the full weight of the ASP.NET server control is not.  In general you won't use these controls very often.

6. What is a sitemap?  Answer

   A sitemap is exactly what it says it is.  A sitemap is a map of the pages in a site.  Sitemaps are primarily used for building navigation menus or breadcrumb controls.  Sitemaps are generally implemented through a static XML file however the sitemap supports an extensible architecture.

   v2 of ASP.NET introduced sitemaps.  Unfortunately, in my opinion, the existing functionality is too limited in most cases.  At a minimal dynamic sitemaps with support for loading them from a database or building them programmatically would have been far more useful.  Rarely are sites truly static these days.  Perhaps MS will fix this in a subsequent release.  In the meantime third-party support has been added for loading sitemaps from a database.  This is, at least, a step in the right direction.

7. What is a user's Profile?  Answer

   A Profile in ASP.NET is a persisted session object created for each user.  The primary benefit of a profile is that it is strongly typed.  A profile is defined in the configuration file for the site.  From this configuration ASP.NET creates a strongly typed class to back the profile.  This class can be used to get and set information about each user in a site including things like their preferred theme settings, start page and perhaps even their browsing history.  Behind the scenes the profile is stored, by default, in a SQL database.  The profile is automatically saved and populated by ASP.NET.  The profile object can store any object that supports serialization although some additional work is needed for complex classes.

   In general use Profile for storing personalization information about a user.  Do not store data in Profile that is already stored in a database somewhere else.

8. What is the difference between StylesheetTheme and Theme on a page?  Answer

   In my opinion this is a logical, but poor, naming convention but we're stuck with it.  A regular theme takes precedence over any ASPX attributes applied to a control.  The theme is applied during the Init phase of the page.  This is great for most themes as a theme forces the entire site to look the same irrelevant of what each page uses.  Since the designer likes to initialize attributes this saves a lot of fixup work that would otherwise be needed.

   A stylesheet theme works similar to a CSS file.  The theme is applied to the server controls prior to the ASPX page attributes being applied.  As a result the stylesheet theme applies a basic set of properties that can then be overridden in an ASPX page.  This is useful for setting properties of ASP.NET controls similiar to how you would set HTML element properties through a CSS file.  Stylesheet themes are applied prior to Init being called on the page.

9. What is the difference between the ID, ClientID and UniqueID properties of a server control?  Answer

   The ID property is set when the control is created.  ASP.NET generally requires that each control in a named scope has a unique identifier. This identifier is generally used for server side programming and will match the name of the underlying field that is created.

   The ClientID is used on the client side to identify the control.  This property is needed when programming JavaScript or other client-side languages.  The primary limitation of the ID property is that it applies to the entire server control.  However oftentimes a server control generates one or more HTML elements. The client identifier is used to uniquely identify the server control in each HTML element.  It is generally the ID with a numeric value added.  Use this property for all client-side programming.

   The UniqueID is a globally unique identifier for the control.  It is a combination of the unique identifier of the parent, named container (such as the page) and the control itself.  This unique identifier is used to help associate a control with its viewstate data on postbacks.

10. What is the HTTP context?  Answer

    This is an actual static class called HttpContext.  Most of the properties available from this class are exposed as properties off the Page class.  However not all classes in an ASP.NET application have access to a page so enter this class.  It exposes, amonst other things, the current HTTP context objects such as the application, Session, Items, Request and Response streams and other useful objects.  Even more useful however is the fact that it also exposes the errors that have occurred during the request.  This is incredibly useful for logging errors after a request has been completed.