En ASP clásico (heredado), hay un puñado de nombres de funciones especiales que, si están definidos en su archivo global.asa, se ejecutarán en puntos específicos durante el ciclo de vida de la aplicación. Estos se definen como:
- Application_OnStart: se ejecuta una vez, cuando la aplicación recibe la primera solicitud HTTP e inmediatamente antes de que se procesen los archivos .ASP.
- Application_On End: se ejecuta una vez, durante el cierre de la aplicación, después de que se hayan procesado todas las solicitudes.
- Session_OnStart: se ejecuta al inicio de cada sesión de usuario única. Si un usuario/cliente tiene las cookies deshabilitadas, esto se ejecuta para cada solicitud porque ASP nunca detecta la cookie de sesión que identifica una sesión existente.
- Session_OnEnd - (teóricamente!) Se ejecuta cada vez que caduca una sesión de usuario. Buena suerte con esto.
Estos están básicamente cableados en el clásico tiempo de ejecución ASP. No puede cambiarlos y no puede adjuntar ningún otro método a estos eventos.
En ASP.NET, hay una cosa llamada AutoEventWireup que utiliza la reflexión para encontrar métodos que se ajusten a las convenciones de nomenclatura particulares, y ejecuta esos métodos en respuesta a eventos coincidentes generados por el tiempo de ejecución de ASP.NET. El ejemplo más común es el método Page_Load, que se invoca automáticamente en respuesta a la clase de página que activa el evento Load durante el ciclo de vida de la página.
La misma técnica se usa para unir controladores a eventos de ciclo de vida de nivel de aplicación. Se buscará métodos llamados ya sea ModuleName_EventName o ModuleName_OnEventName, teniendo bien no hay parámetros () o (object sender, EventArgs e)
Aquí está la parte divertida - si se define más de un método de emparejamiento, sólo el que aparece último en el archivo se ejecutará. (El último método gana, básicamente)
Así que si sus global.asax.cs se parece a esto:
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)");
}
}
verá el mensaje D en su salida de depuración; si comenta el último método en ese bloque, verá el mensaje C en su lugar.
Por lo tanto, utilice cualquiera de las convenciones de nomenclatura que desee, pero si define más de una, solo se ejecutará la última que aparezca en su archivo fuente. Me quedaría personalmente con Application_Start(object sender, EventArgs e) ya que esa es la firma generada por las plantillas de proyectos de Visual Studio y la mayoría de las herramientas de diseño/codificación de .NET.
Gran explicación, especialmente con las diferentes firmas de métodos. –
Tengo una pregunta sobre esta explicación. Cuando dice "se ejecuta una vez, antes de que se procesen los archivos .ASP", ¿eso significa que el proceso se ejecuta cuando se inicia el servidor o al comienzo de cada conexión HTTP? Si el primero, ¿sería posible crear una instancia de un singleton que pueda ejecutar un proceso en segundo plano que debería ejecutarse durante la vida útil de la aplicación? –
@ miken.mkndev La aplicación no lo hace hasta que recibe una solicitud HTTP. Cuando llegue esta solicitud, IIS iniciará el proceso de solicitud, ejecutará cualquier evento de Application_Start y ENTONCES procesará la solicitud entrante. Es común que los scripts de implementación desplieguen una nueva versión de la aplicación y luego realizan una solicitud HTTP para iniciar la aplicación de inmediato, especialmente si Application_Start tarda varios segundos en completarse. Es mejor hacer esto por adelantado que penalizar al usuario desafortunado que es su primer visitante después de una implementación. –