The following information applies to ASP.NET 2.0
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).
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.
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.
Here are the methods the runtime will look for when AutoEventWireup is true.
When AutoEventWireup is true, the runtime has to look for each of the page event handlers using code like the following.
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.
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
Thanks
bill
I use code snippets (even faster than using the mouse, for me). I'll have to post them here at some point.
(see www.aspnetresources.com/...)
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.
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
AutoEventWireup happens at runtime.
The documentation is wrong.
It's not like I make this stuff up, you know. I actually do some homework. ;)
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.
thnx
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.
Why are Microsoft so unwilling to document something that can degrade the performance of a Web-Site so dramattically?
Good post btw, thanks!
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.
but the difference is that this is an override, not an AutoEventWireup:
override protected void OnInit(EventArgs e)
Ciao... Sven