Inside AutoEventWireup

The following information applies to ASP.NET 2.0

Basics

The default value for AutoEventWireup is true for a C# web form, and false for a VB.NET web form. The IDE adds the default values to the @ Page directive for a new web form. The difference in defaults is partly because VB.NET has a mechanism for defining an event handler and subscribing to an event in one graceful motion (the Handles keyword).

Protected Sub Page_Load(ByVal sender As Object, _
                        
ByVal e As System.EventArgs) _
                        
Handles Me.Load
    
' ...

End Sub

An easy way to generate the above code is to use the drop down controls that sit just above the editor. Note: C# doesn’t make the dropdown list of events available when editing a code-beside file, but the dropdown is available when writing in-line code.

There is no equivalent to the Handles keyword in C# (anonymous event handlers are arguably close, but just not the same). When AutoEventWireup is true, all we need to do is follow the method naming convention of Page_EventToHandle. The ASP.NET runtime will automatically find and fire the method for the appropriate event.

protected void Page_Load(object sender, EventArgs e)
{

}

Once Again, In Reverse

If we switch to AutoEventWireup=”true” for a VB.NET web form, we can use the magic Page_EventName approach. The only change to the earlier VB.NET code would be to drop the Handles clause, and the events fire correctly.

If we switch to AutoEventWireup=”false” for a C# web form, there is a little extra work to do. Somewhere we need to explicitly wire up events. Here is one approach.

public partial class _Default : Page
{
  
public _Default() // ctor
   {
      Load +=
new EventHandler(Page_Load);
      PreInit +=
new EventHandler(Page_PreInit);        
   }

    
protected void Page_Load(object sender, EventArgs e)
    {
      
// ...
    }

  
protected void Page_PreInit(object sender, EventArgs e)
   {
      
// ...
   }
}

Here are the methods the runtime will look for when AutoEventWireup is true.

  • Page_PreInit
  • Page_Init
  • Page_InitComplete
  • Page_PreLoad
  • Page_Load
  • Page_LoadComplete
  • Page_DataBind
  • Page_SaveStateComplete
  • Page_PreRender
  • Page_PreRenderComplete
  • Page_Unload
  • Page_Error
  • Page_AbortTransaction
  • Page_CommitTransaction

Trivia

When AutoEventWireup is true, the runtime has to look for each of the page event handlers using code like the following.

bool ignoreCase = true;
bool throwOnFailure = false;
Delegate d = null;

d =
Delegate.CreateDelegate(
                      
typeof(EventHandler), this,
                      
"Page_Load", ignoreCase,
                      throwOnFailure
                    );

Notice the member search is case-insensitive, which isn’t surprising since VB.NET is case-insensitive. What is surprising (to me) is that the following works, too.

protected void Page_Load()
{
  
// ...
}

If the runtime can’t make an EventHandler delegate, it will then try to make a delegate to a method with an empty parameter list. Yes, that's up to 28 calls to CreateDelegate per web form with AutoEventWireup="true".

Print | posted @ Friday, February 17, 2006 3:37 AM

Comments on this entry:

Gravatar # re: Inside AutoEventWireup
by Tarun at 2/17/2006 9:52 AM

WOW!! Very insightful post Scott.
Thanks
  
Gravatar # re: Inside AutoEventWireup
by William Robertson at 2/17/2006 3:27 PM

I really wish they could "activate" the event drop down list from the code behind forms for C#.

bill
  
Gravatar # re: Inside AutoEventWireup
by scott at 2/17/2006 3:42 PM

Bill:

I use code snippets (even faster than using the mouse, for me). I'll have to post them here at some point.
  
Gravatar # re: Inside AutoEventWireup
by Milan Negovan at 2/17/2006 8:19 PM

All this applies to how event handlers are wired in global.asax, too. This subject always confused me until I cranked out the mighty Reflector and...
(see www.aspnetresources.com/...)
  
Gravatar # re: Inside AutoEventWireup
by Grim at 2/23/2006 2:25 PM

Is there a convenient way to configure C# so that the default AutoEventWireup is false instead of true?

I've always preferred to use the OnXxxxx... overrides instead of the event wireups, anyway. But I frequently forget to go back and change the AutoEventWireup on every page.

Also, we'll soon be doing more ASP.Net development across the entire dev team, and I'd like to have a way to "strongly encourage" people to use overrides instead of events.
  
Gravatar # re: Inside AutoEventWireup
by scott at 2/23/2006 2:52 PM

Grim:

I think you'll want to define a custom template for your team. It is relatively easy but the consistency you'll get makes up for any work it takes.

ScottGu has a good post on the topic:
weblogs.asp.net/.../424780.aspx
  
Gravatar # re: Inside AutoEventWireup
by Mac at 3/10/2006 1:28 AM

Per documentation: "At compilation time, ASP.NET will find methods based on this naming convention and automatically perform the binding between the event and the method." AutoEventWireup at compilation time not run time.
  
Gravatar # re: Inside AutoEventWireup
by scott at 3/10/2006 2:57 AM

Take a look at the code with Reflector (both the generated code, and code in System.Web.dll).

AutoEventWireup happens at runtime.

The documentation is wrong.

It's not like I make this stuff up, you know. I actually do some homework. ;)
  
Gravatar # re: Inside AutoEventWireup
by Ryan at 3/16/2006 6:55 PM

This is probably painfully obvious for most people, but since it's related...

If you use the "Handles" keyword to subscribe to a *control* event, be sure that the event is also not referenced explicitly by the control itself in your presentation layer, otherwise the event will be called twice. E.g. If you use the syntax <asp:Button OnClick="Button1_Click".../> and the Handles Button1_Click syntax together.

I don't know if there are any performance considerations from using "Handles" for control events versus the explicit syntax. I'm guessing not much of anything since the delegate has to match the exact syntax (and it's matched at compile time unlike page?), and you can't get away with an empty parameter list like with Page.

People who used to use the explicit syntax and are motivated by this blog post to move to AutoEventWireup="false" and thus using the VS drop down more will want to double check that they don't do both accidentally, as it's not usually obvious that an event is getting called twice unless you are appending and not merely filling in content or such.
  
Gravatar # re: Inside AutoEventWireup
by scott at 3/16/2006 7:28 PM

Good point, Ryan. Thus the number of people who ask: "why is my event firing twice?"!
  
Gravatar # re: Inside AutoEventWireup
by satish kumar suthar at 4/7/2006 7:36 AM

it's really helpful post helping gain knowledge.
thnx
  
Gravatar # re: Inside AutoEventWireup
by Sharee at 5/27/2006 7:52 PM

I have read dozens of articles that kept stating by default the AutoEventWireup was false. This is the first article that differentiated VB and C#. Thanks for the clarification.
  
Gravatar # re: Inside AutoEventWireup
by william at 9/1/2006 5:56 AM

Sharee:

In ASP.NET 1.1, the AutoEventWireup attribute in the @page directive is false by default (for C# projects).

But in ASP.NET 1.1, some dumb jerk in the ASP.NET team changed it true, presumably to make life easier for developers.

I think lots of stuff in ASP.NET 2.0 are pretty flaky. For example, the new web site compilation model that most existing asp.net projects cannot easily upgrade to. Eventually, they had to ship a separate Web Application Project addon to fix this. Those guys were too ambitious.
  
Gravatar # re: Inside AutoEventWireup
by Kieron at 10/23/2006 1:12 PM

So where is that in the MSDN Library?

Why are Microsoft so unwilling to document something that can degrade the performance of a Web-Site so dramattically?

Good post btw, thanks!
  
Gravatar # re: Inside AutoEventWireup
by scott at 10/23/2006 1:24 PM

Kieron: Good question. I had to dig around to get this information.
  
Gravatar # re: Inside AutoEventWireup
by faramak at 11/2/2006 12:05 AM

well, i am not sure if the AutoEventWireup="false" option is that efficient. Consider that in 1.1 your calls to events were through:

override protected void OnInit(EventArgs e)
{
//
// CODEGEN: This call is required by the ASP.NET Web Form Designer.
//
InitializeComponent();
base.OnInit(e);
}

---------------------------------
thus, even though you decalred AutoEventWireup="False", it seems you were cheated, for at least this one, i.e. "OnInit()" it seemed to be "True".

so, i think, perhaps we were fooling ourselves?
in trying to treat writing to an asp.net page as if we are writing to a regular code file, which it is not.

i think it be better if developers are presented with all the complexity of the asp.net page, rather than keep it in black-box and make it seem as if it's just a code file, which it is not.

and try to see what's under the hood, and you can only find a few outsiders to microsoft who end up surmising at the deep levels.

----------------
so, i think 2.0 is trying to come out more honest about the state of affairs. as much as a black box permits.
  
Gravatar # re: Inside AutoEventWireup
by Jonathan B. at 1/10/2007 9:48 PM

faramak, I'm sure you know this but just didn't catch it ...

but the difference is that this is an override, not an AutoEventWireup:

override protected void OnInit(EventArgs e)
  
Gravatar # re: Inside AutoEventWireup
by Sven B. Schreiber at 1/15/2007 5:43 PM

Thanks, Scott! This is the first article I found that REALLY explains what this AutoEventWireup is all about.

Ciao... Sven
  

Your comment:

Title:
Name:
Email:
Website:
 
Italic Underline Blockquote Hyperlink
 
 
Please add 2 and 6 and type the answer here: