Inside AutoEventWireup

Friday, February 17, 2006

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".


Comments
Tarun Friday, February 17, 2006
WOW!! Very insightful post Scott.
Thanks
William Robertson Friday, February 17, 2006
I really wish they could "activate" the event drop down list from the code behind forms for C#.

bill
scott Friday, February 17, 2006
Bill:

I use code snippets (even faster than using the mouse, for me). I'll have to post them here at some point.
Milan Negovan Friday, February 17, 2006
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/...)
Grim Thursday, February 23, 2006
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.
scott Thursday, February 23, 2006
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
Mac Friday, March 10, 2006
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.
scott Friday, March 10, 2006
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. ;)
Ryan Thursday, March 16, 2006
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.
scott Thursday, March 16, 2006
Good point, Ryan. Thus the number of people who ask: "why is my event firing twice?"!
satish kumar suthar Friday, April 7, 2006
it's really helpful post helping gain knowledge.
thnx
Sharee Saturday, May 27, 2006
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.
william Friday, September 1, 2006
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.
Kieron Monday, October 23, 2006
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!
scott Monday, October 23, 2006
Kieron: Good question. I had to dig around to get this information.
faramak Thursday, November 2, 2006
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.
Jonathan B. Wednesday, January 10, 2007
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)
Sven B. Schreiber Monday, January 15, 2007
Thanks, Scott! This is the first article I found that REALLY explains what this AutoEventWireup is all about.

Ciao... Sven
baig Saturday, March 20, 2010
excellent !!
adnan Sunday, September 19, 2010
i got exact answer which i have been looking for on this page thanks man
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!