Difference between Application_Start and Application_OnStart

Question

I'm in the process of adding ASP.NET MVC code to a preexisting ASP.NET Webforms project. The various tutorials suggest adding routing to a method called from Application_Start() in Global.asax. My Global.asax already has an Application_OnStart(Object,EventArgs) method with some setup code.

If I try to have both Start and OnStart, the OnStart doesn't get called (and the setup fails, causing errors). It looks like I have to choose one or the other.

My question is: which one should I be using? What is the difference between them? Are they called at different times?

(Note: at the time of this writing, the top three Google hits are useless and/or misleading. I'm hoping Stack Overflow can fix that.)

Answer 1

In classic (legacy) ASP, there are a handful of special function names that, if defined in your global.asa file, will be run at specified points during the application lifecycle. These are defined as:

• Application_OnStart - runs once, when your application receives the first HTTP request and immediately before any .ASP files are processed.
• Application_OnEnd - runs once, during application shutdown, after all requests have been processed.
• Session_OnStart - runs at the start of each unique user session. If a user/client has cookies disabled, this runs for every request because ASP never detects the session cookie identifying an existing session.
• Session_OnEnd - (theoretically!) runs each time a user session expires. Good luck with this.

These are basically hard-wired into the classic ASP runtime - you can't change them, and you can't attach any other methods to these events.

In ASP.NET, there's a thing called AutoEventWireup that uses reflection to find methods conforming to particular naming conventions, and runs those methods in response to matching events raised by the ASP.NET runtime. The most common example is the Page_Load method, which is automatically invoked in response to the Page class firing the Load event during the page lifecycle.

The same technique is used to attach handlers to application-level lifecycle events. It will look for methods named either ModuleName_EventName or ModuleName_OnEventName, taking either no parameters () or (object sender, EventArgs e)

Here's the fun part - if you define more than one matching method, only the one that appears latest in the file will execute. (The last method wins, basically)

So if your global.asax.cs looks like this:

public class Global : System.Web.HttpApplication {
    protected void Application_Start() {
        Debug.WriteLine("A: Application_Start()");
    }

    protected void Application_Start(object sender, EventArgs e) {
        Debug.WriteLine("B: Application_Start(object sender, EventArgs e)");
    }

    protected void Application_OnStart() {
        Debug.WriteLine("C: Application_OnStart()");

    }
    protected void Application_OnStart(object sender, EventArgs e) {
        Debug.WriteLine("D: Application_OnStart(object sender, EventArgs e)");
    }
}

you'll see message D in your debug output; if you comment out the last method in that block, you'll see message C instead.

So - use whichever naming convention you like, but if you define more than one, only the one that appears last in your source file will be executed. I would personally stick with Application_Start(object sender, EventArgs e) since that's the signature generated by the Visual Studio project templates and most .NET design/coding tools.