Tag Archives: context

Building the Http Module with Logging Application Block

Building the Http Module

In order to build an Http module we only need to implement
the IHttpModule interface. The following is a simple
LoggingHttpModule which log details when a web request start
and when web request end:

using System;
using System.Web;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Logging;
namespace HttpModules
  public class LoggingHttpModule : IHttpModule
    #region Members
    private LogWriter _writer;
    #region IHttpModule Members
    public void Dispose()
      if (_writer != null)
    public void Init(HttpApplication context)
      context.BeginRequest += new EventHandler(context_BeginRequest);
      context.EndRequest += new EventHandler(context_EndRequest);
    private void CreateLogWriter()
      _writer = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();
    private void ConfigureEnterpriseLibraryContainer()
      var builder = new ConfigurationSourceBuilder();
               .FlatFile("Log File")
               .FormatWith(new FormatterBuilder()
      var configSource = new DictionaryConfigurationSource();
      EnterpriseLibraryContainer.Current =
    void context_BeginRequest(object sender, EventArgs e)
      _writer.Write(new LogEntry
        Message = "BeginRequest"
    void context_EndRequest(object sender, EventArgs e)
      _writer.Write(new LogEntry
        Message = "EndRequest"

Using The Module

In order to use the module all we need to do is to add a reference
to the class library that holds the LoggingHttpModule. Then we need
to register the module in the web.config file in the httpModules 
element like:

    <add name="LoggingHttpModlue" type="HttpModules.LoggingHttpModule, HttpModules"/>

That is it. Now the module will be executed whenever a request
start or end.

How to Hack the ASP.NET Parser

The ASP.NET compliation system is pretty complex. There are all kinds of extensibility points, including BuildProviders, PageParserFilters, ControlBuilders, ExpressionBuilders and the list goes on. One unknown *feature* of the parser is it’s ability to generate code from something called an InstanceDescriptor.

The parser has a special way of dealing with ITemplate properties so if we try to do this:

<asp:Repeater ID="repeater" runat="server" ItemTemplate="~/MyUserControl.ascx">

It fails because the there is no way to convert the string “~/MyUserControl.ascx” into an ITemplate.

The parser uses the TypeConverter attribute defined on properties it parses to aid in the conversion.  Enter TypeDescriptionProvider. These complex beasts are used at the heart of all designers in Visual Studio. There are used for things like populating the property grid, and adding and removing properties dynamically, basically a general purpose metadata API (think of it as an abstraction on top of reflection).


The code we are going to generate will instantiate a VirtualPathTemplate with a virtual path pointing to a user control on our site. Normally when you define a template in markup, a special type called CompiledTemplateBuilder (which points to a delegate that builds the template at runtime) is assigned to it. We want to replace a line of code that looks like this:

repeater.ItemTemplate = new CompiledTemplateBuilder(BuildTemplate);

to this

repeater.ItemTemplate = new VirtualPathTemplate("~/MyUserControl.ascx");


After overriding about 4 classes (TypeDescriptionProvider, CustomTypeDescriptor, PropertyDescriptor, and finally TypeConverter) we are able to control what happens when the parser asks, “can we convert “~/MyUserControl.ascx” to an ITemplate?”.

Here is the code for the TemplateTypeConverter:

public override bool CanConvertTo(ITypeDescriptorContext context, Type destinationType) {
// Allow InstanceDescriptor so that the code gen engine can use it to generate the correct
// code for the ITemplate property
return destinationType == typeof(InstanceDescriptor) || _converter.CanConvertTo(context, destinationType);
public override object ConvertTo(ITypeDescriptorContext context, CultureInfo culture, object value, Type destinationType) {
var descriptorProvider = value as IInstanceDescriptorProvider;
if (descriptorProvider != null) {
return descriptorProvider.Descriptor;
return _converter.ConvertTo(context, culture, value, destinationType);
public override bool CanConvertFrom(ITypeDescriptorContext context, Type sourceType) {
return sourceType == typeof(string) || _converter.CanConvertFrom(context, sourceType);
public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value) {
string stringValue = value as string;
if (stringValue != null) {
if (stringValue.StartsWith("~/")) {                    
// Assume this is a virtual path and return the instance description provider
// for it
return new VirtualPathInstanceDescriptorProvider(stringValue);
return _converter.ConvertFrom(context, culture, value);

First the parser asks the converter if it can convert from a string so we always say yes. In ConvertFrom we try to convert the value to a string and check if the path starts with “~/” in order to determine if it’s a virtual path. If it is a virtual path we return an object that knows how to get an InstanceDescriptor from the virtual path (VirtualPathInstanceDescriptorProvider). Now we have successfully parsed the control.

Next the code generator tries to generate code for the ITemplate property. The code generator will eventually ask if it can convert the object we returned earlier (VirtualPathInstanceDescriptorProvider) to an InstanceDescriptor. The implementation of VirtualPathInstanceDescriptorProvider returns an instance descriptor that wraps a constructor info for a custom template we are going to use:

internal class VirtualPathInstanceDescriptorProvider : IInstanceDescriptorProvider {
private string _virtualPath;
private static ConstructorInfo s_Constructor = GetConstructor();
private static ConstructorInfo GetConstructor() {
return typeof(VirtualPathTemplate).GetConstructor(new[] { typeof(string) });
public InstanceDescriptor Descriptor {
get {
return new InstanceDescriptor(s_Constructor, new[] { _virtualPath });
public VirtualPathInstanceDescriptorProvider(string virtualPath) {            
        _virtualPath = virtualPath;

The code generation engine then generates the resulting code we wanted to specify above using the constructor info and virtual path.

At runtime we use BuildManager.CreateInstanceFromVirtualPath(“~/MyUserControl.ascx”) to create an instance of the user control and add it to the control’s collection and we’re done.

public class VirtualPathTemplate : ITemplate {
private string _virtualPath;
public VirtualPathTemplate(string virtualPath) {
        _virtualPath = virtualPath;
public void InstantiateIn(Control container) {
// Try to create the control from the virtual path
Control control = (Control)BuildManager.CreateInstanceFromVirtualPath(_virtualPath, typeof(Control));
if (control != null) {
// Add it to the controls collection