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