Le véritable point d'entrée dans le runtime .NET se produit dans certaines classes et interfaces non documentées (Traduction : bien sûr, vous pouvez utiliser Reflector pour afficher J. Très peu de personnes, à l'exception de Microsoft, connaissent ces interfaces, et les gars de Microsoft ne les aiment pas). parler de ces détails. Ils pensent que ces détails d'implémentation sont de peu d'utilité pour les développeurs qui utilisent ASP.NET pour développer des applications.
Le processus de travail (ASPNET_WP.EXE dans IIS5, W3WP.EXE dans IIS6) héberge le runtime .NET et la DLL ISAPI. Il (le processus de travail) appelle une petite interface non gérée de l'objet COM et envoie finalement l'appel à la classe ISAPIRuntime. Sur une instance (Annotation : le texte original est une sous-classe d'instance de la classe ISAPIRuntime, mais la classe ISAPIRuntime est une classe scellée, qui est soupçonnée d'être une erreur d'écriture de la part de l'auteur, ou sous-classe ici ne signifie pas sous-classe la première). entrée dans le runtime est Cette classe non documentée implémente l'interface IISAPIRuntime (pour la spécification de l'appelant, cette interface est une interface COM). Cette interface COM sous-jacente basée sur IUnknown est une interface prédéterminée étendue d'ISAPI à ASP.NET. interface et sa signature d'appel (en utilisant l'excellent outil .NET Reflector de Lutz Roeder http://www.aisto.com/roeder/dotnet/). C'est un bon moyen d'explorer cette méthode étape par étape.
Figure 3 - Si vous souhaitez approfondir cette interface, ouvrez Reflector et pointez sur l'espace de noms System.Web.Hosting. La DLL ISAPI ouvre l'accès à ASP.NET en appelant une interface COM hébergée qui reçoit une interface non binaire. lien pointant vers le pointeur ISAPI ECB. Cet ECB contient la possibilité d'accéder à l'interface ISAPI complète utilisée pour recevoir des demandes et renvoyer des réponses à IIS.
L'interface IISAPIRuntime sert de point d'interface entre le code non géré s'étendant d'ISAPI et d'ASP.NET.
(
directement lié dans IIS6)
. (via Named Pipes dans IIS5)
ecb,
[In, MarshalAs(UnmanagedType.I4)] int useProcessModel);
le paramètre ecb est le bloc de contrôle d'extension ISAPI (bloc de contrôle d'extension), qui est transmis à la fonction ProcessRequest en tant que ressource non gérée. Interface d'entrée et de sortie de base, utilisée avec les objets Request et Response. ISAPI ECB contient toutes les informations de requête de bas niveau, telles que les variables du serveur, les flux d'entrée pour les variables de formulaire et les flux de sortie pour l'écriture des données au client. toutes les fonctionnalités permettant d'accéder à une ressource accessible par les requêtes ISAPI. ProcessRequest est le point d'entrée et de sortie initial de cette ressource (ecb) vers le code géré.
Les extensions ISAPI gèrent les requêtes de manière asynchrone. Dans ce mode, l'extension ISAPI renvoie immédiatement l'appel à. le processus de travail ou le thread IIS, mais l'ECB restera disponible pendant toute la durée de vie de la demande en cours. L'ECB contient un mécanisme permettant à ISAPI de savoir que la demande a été traitée (via la méthode ecb.ServerSupportFunction) (Annotation : Plus d'informations , voir l'article sur le développement d'extensions ISAPI), ce qui entraîne la libération de l'ECB. Cette méthode de traitement asynchrone libère immédiatement le thread de travail ISAPI et transmet le traitement à un thread distinct géré par ASP.NET.
ASP.NET reçoit la référence à ecb et. utilisez-le en interne pour recevoir des informations sur la requête en cours, telles que les variables du serveur et les données POST. Il renvoie également des informations au serveur qui reste accessible (reste en vie) jusqu'à ce que la requête soit terminée ou que le délai d'attente expire. continuez à communiquer avec lui jusqu'à ce que le traitement de la demande soit terminé. La sortie est écrite dans le flux de sortie ISAPI (à l'aide de ecb.WriteClient()) et la demande est terminée. L'extension ISAPI est informée que le traitement de la demande est terminé et libère l'ECB. . Cette implémentation est très efficace, car les classes .NET ne sont essentiellement qu'un wrapper très "mince" autour de l'ECB ISAPI efficace et non géré.
Chargement de .NET - un peu mystérieux
.Prenons du recul à partir d'ici : I Sauter comment le. Le runtime .NET est chargé. C'est là que les choses deviennent un peu floues. Je n'ai trouvé aucune documentation sur ce processus, et puisque nous parlons de code natif, il n'y a pas de bon moyen de le faire. comprendre (le code qui charge le runtime .NET).
La meilleure supposition que je puisse faire est que lorsque l'extension ISAPI reçoit la première demande d'extension qui correspond à ASP.NET, le processus charge le runtime .NET. Une fois le runtime existant, le code non managé peut demander une instance de ISAPIRuntime pour un répertoire virtuel spécifié s'il n'existe pas déjà. Chaque répertoire virtuel possède son propre domaine d'application (AppDomain), lorsqu'il s'agit d'une application indépendante (faisant référence à un programme ASP.NET). est démarré, ISAPIRuntime a toujours existé dans le domaine d'application depuis le processus de démarrage. L'instanciation (Annotation : doit faire référence à l'instanciation d'ISAPIRuntime) semble se faire via COM. Cela est dû au fait que les méthodes d'interface sont exposées en tant que méthodes appelables par COM
lors du premier démarrage
.Lorsqu'une demande de répertoire virtuel arrive, la fonction System.Web.Hosting.AppDomainFactory.Create() est appelée pour créer une instance d'ISAPIRuntime. Cela démarre le processus de démarrage de l'application. Cet appel reçoit le type de l'application, le nom du module et les informations sur le répertoire virtuel. , qui est utilisé par ASP.NET pour créer le domaine d'application et démarrer le programme ASP.NET pour ce répertoire virtuel Les instances HttpRuntime (Annotation : le texte original est cet objet dérivé de HttpRuntime, mais HttpRuntime est une classe scellée, ce qui est suspecté. (il s'agit d'une erreur dans le texte original) sont créés dans un nouveau domaine d'application. Chaque répertoire virtuel (c'est-à-dire qu'une application ASP.NET est hébergée) est hébergé dans un domaine d'application distinct et ils ne seront chargés que lorsqu'un ASP spécifique est installé. Le programme .NET est demandé. L'extension ISAPI gère les instances de ces objets HttpRuntime et achemine les requêtes internes en fonction du répertoire virtuel demandé vers l'objet HttpRuntime correct.
Figure 4 : Les requêtes ISAPI sont envoyées au pipeline HTTP d'ASP.NET à l'aide de classes et d'interfaces non documentées et en appelant de nombreuses méthodes d'usine. Chaque application Web/répertoire virtuel s'exécute dans son propre domaine d'application, et l'appelant (Annotation : DLL ISAPI) conserve une référence. à l'interface IISAPIRuntime pour déclencher le traitement des requêtes ASP.NET.