El verdadero punto de entrada al tiempo de ejecución de .NET ocurre en algunas clases e interfaces no documentadas (Traducción: por supuesto, puede usar Reflector para ver J). Muy pocas personas, excepto Microsoft, conocen estas interfaces y los chicos de Microsoft no están interesados en ellas. Hablando de estos detalles, creen que estos detalles de implementación son de poca utilidad para los desarrolladores que usan ASP.NET para desarrollar aplicaciones.
El proceso de trabajo (ASPNET_WP.EXE en IIS5, W3WP.EXE en IIS6) aloja el tiempo de ejecución de .NET y la DLL de ISAPI. (El proceso de trabajo) llama a una pequeña interfaz no administrada del objeto COM y finalmente envía la llamada a la clase ISAPIRuntime. En una instancia (Anotación: el texto original es una subclase de instancia de la clase ISAPIRuntime, pero la clase ISAPIRuntime es una clase sellada, lo que se sospecha que es un error administrativo por parte del autor, o subclase aquí no significa subclase La primera). La entrada al tiempo de ejecución es Esta clase no documentada implementa la interfaz IISAPIRuntime (para la especificación del llamante, esta interfaz es una interfaz COM subyacente basada en IUnknown es una interfaz predeterminada extendida de ISAPI a ASP.NET). interfaz y su firma de llamada (utilizando la excelente herramienta .NET Reflector de Lutz Roeder http://www.aisto.com/roeder/dotnet/). Esta es una buena manera de explorar este método paso a paso.
Figura 3: si desea profundizar en esta interfaz, abra Reflector y seleccione el espacio de nombres System.Web.Hosting. La DLL ISAPI abre el acceso a ASP.NET llamando a una interfaz COM alojada que recibe un formato no binario. enlace que apunta al puntero administrado de ISAPI. Este ECB contiene la capacidad de acceder a la interfaz ISAPI completa utilizada para recibir solicitudes y enviar respuestas a IIS.
La interfaz IISAPIRuntime sirve como punto de interfaz entre el código no administrado que se extiende desde ISAPI y ASP.NET. (directamente relacionado en IIS6 (a través de Named Pipes en IIS5) Si busca dentro de esta clase, encontrará la función ProcessRequest con la siguiente firma:
[return: MarshalAs(UnmanagedType.I4)]
int ProcessRequest([In] IntPtr). ecb,
[In, MarshalAs(UnmanagedType.I4)] int useProcessModel);
el parámetro ecb es el bloque de control de extensión ISAPI (bloque de control de extensión), que se pasa a la función ProcessRequest como un recurso no administrado. Interfaz básica de entrada y salida, utilizada con objetos de solicitud y respuesta de ISAPI ECB, que contiene toda la información de solicitud de bajo nivel, como variables del servidor, flujos de entrada para variables de formulario y flujos de salida para escribir datos al cliente. toda la funcionalidad para acceder a un recurso al que pueden acceder las solicitudes ISAPI. ProcessRequest es el punto de entrada y salida inicial para este recurso (ecb) para que
las extensiones ISAPI manejen las solicitudes de forma asincrónica. el proceso de trabajo o el subproceso IIS, pero el ECB permanecerá disponible durante la vida útil de la solicitud actual. El ECB contiene un mecanismo para informar a ISAPI que la solicitud ha sido procesada (a través del método ecb.ServerSupportFunction) (Anotación: Más para obtener información). , consulte el artículo sobre el desarrollo de extensiones ISAPI), lo que hace que se libere el ECB. Este método de procesamiento asincrónico libera inmediatamente el subproceso de trabajo ISAPI y pasa el procesamiento a un subproceso separado administrado por ASP.NET.
ASP.NET recibe Referencia a ecb. úselo internamente para recibir información sobre la solicitud actual, como variables del servidor y datos POST. También devuelve información al servidor que permanece accesible (permanece activo) hasta que se completa la solicitud o expira el tiempo de espera. continúe comunicándose con él hasta que se complete el procesamiento de la solicitud. La salida se escribe en el flujo de salida ISAPI (usando ecb.WriteClient()) y se completa la solicitud. Se notifica a la extensión ISAPI que el procesamiento de la solicitud se ha completado y libera al BCE. Esta implementación es muy eficiente, porque las clases .NET son esencialmente un contenedor muy "delgado" alrededor del eficiente y no administrado ISAPI ECB.
Un poco misterioso
.Retrocedamos un poco desde aquí: I Saltando cómo funciona. Se carga el tiempo de ejecución de .NET. Aquí es donde las cosas se ponen un poco confusas. No encontré ninguna documentación sobre este proceso y, dado que estamos hablando de código nativo, no hay una buena manera de hacerlo para descompilar la DLL de ISAPI. descúbrelo (el código que carga el tiempo de ejecución de .NET).
La mejor suposición que puedo hacer es que cuando la extensión ISAPI recibe la primera solicitud de una extensión que se asigna a ASP.NET, el proceso carga el tiempo de ejecución de .NET. Una vez que existe el tiempo de ejecución, el código no administrado puede solicitar una instancia de ISAPIRuntime para un directorio virtual específico si aún no existe. Cada directorio virtual tiene su propio dominio de aplicación (AppDomain), cuando es una aplicación independiente (en referencia a un programa ASP.NET).
Cuando
se inicia, ISAPIRuntime siempre ha existido en el dominio de la aplicación desde el proceso de inicio. La creación de instancias (Anotación: debe referirse a la creación de instancias de ISAPIRuntime) parece ser a través de COM. Esto se hace porque los métodos de la interfaz se exponen como métodos invocables COM.
Cuando llega la solicitud de un directorio virtual, se llama a la función System.Web.Hosting.AppDomainFactory.Create() para crear una instancia de ISAPIRuntime. Esto inicia el proceso de inicio de la aplicación. Esta llamada recibe el tipo de aplicación, el nombre del módulo y la información del directorio virtual. , que ASP.NET utiliza para crear el dominio de la aplicación e iniciar el programa ASP.NET para este directorio virtual. Las instancias de HttpRuntime (Anotación: el texto original es este objeto derivado de HttpRuntime, pero HttpRuntime es una clase sellada, lo cual se sospecha. (ser un error en el texto original) se crean en un nuevo dominio de aplicación. Cada directorio virtual (es decir, una aplicación ASP.NET está alojada) se aloja en un dominio de aplicación independiente y solo se cargarán cuando se ejecute un ASP específico. Se solicita el programa .NET. La extensión ISAPI administra instancias de estos objetos HttpRuntime y enruta las solicitudes internas según el directorio virtual solicitado al objeto HttpRuntime correcto.
Figura 4: Las solicitudes ISAPI se envían a la canalización HTTP de ASP.NET utilizando algunas clases e interfaces no documentadas y llamando a muchos métodos de fábrica. Cada aplicación web/directorio virtual se ejecuta en su propio dominio de aplicación, y la persona que llama (Anotación: ISAPI DLL) mantiene una referencia. a la interfaz IISAPIRuntime para activar el procesamiento de solicitudes ASP.NET.