Asp. NET underlying architecture exploration into the. NET Runtime

Asp.net| Architecture

Enter. NET runtime's real portal occurs in some classes and interfaces that are not documented (translated: Of course, you can look at J with reflector). Few people know about these interfaces except Microsoft, and Microsoft's guys are not keen to talk about these details, They consider these implementation details to be of little use to developers who are using ASP.net development applications.

The work process (IIS5 is aspnet_wp. EXE,IIS6 is W3WP.EXE) boarding. NET runtime and ISAPI DLLs, which (worker processes) eventually send calls to an instance of the Isapiruntime class by calling a small unmanaged interface to a COM object (the original is an instance subclass of the Isapiruntime class, but Isapiruntime is a sealed class, the author of a pen error, or subclass here is not the meaning of subclasses. The first entry into the runtime is this class that is not documented. This class implements the Iisapiruntime interface (this interface is a COM interface for the caller's description) This underlying COM interface based on IUnknown is a predetermined interface extended from ISAPI to asp.net. Figure 3 shows the Iisapiruntime interface and its invocation signature. (using the Lutz Roeder excellent. NET Reflector tool http://www.aisto.com/roeder/dotnet/). This is a good way to explore this step-by-step process.

　　

Figure 3-If you want to drill into this interface, open reflector and point to the System.Web.Hosting namespace. The ISAPI DLL opens the portal into the ASP.net by invoking a managed COM interface, ASP. NET receives an unmanaged pointer to the ISAPI ECB. This ECB includes the ability to access the full ISAPI interface to receive requests and send responses back to IIS.

The Iisapiruntime interface is directly connected to the interface point between unmanaged code and asp.net from the ISAPI extension (IIS6, IIS5 through Named pipes). If you look inside the class, you'll find the ProcessRequest function that contains the following signature :

[Return:marshalas (UNMANAGEDTYPE.I4)]

int ProcessRequest ([in] IntPtr ECB,

[In, MarshalAs (UNMANAGEDTYPE.I4)] int useprocessmodel);

The ECB parameter is the ISAPI extension control block, which is passed as an unmanaged resource to the ProcessRequest function. This function takes the ECB as the basic input-output interface, and the extention Used with the request and response objects. The ISAPI ECB contains all the underlying request information, such as server variables, for forms (form) The input stream of the variable and the output stream used to write back the data to the client. This ECB reference basically provides the full functionality to access the resources that the ISAPI request can access, and ProcessRequest is the first time this resource (ECB) has come into contact with the entry and exit of managed code.

The ISAPI extension processes requests asynchronously. In this mode, the ISAPI extension returns calls to the worker process or to the IIS thread immediately, but the ECB remains available on the life cycle of the current request. The ECB contains mechanisms that enable ISAPI to know that requests have been processed (via the ECB). ServerSupportFunction method) (For more information, refer to the article developing the ISAPI extension), which allows the ECB to be released. This asynchronous processing can immediately release the ISAPI worker thread, and passes the processing to a separate thread managed by asp.net.

Asp. NET receives the ECB reference and uses it internally to receive information about the current request, such as server variables, post data, and it also returns information to the server. The ECB remains accessible (stay alive) before the request completes or before the timeout period. So asp.net can continue to communicate with it until the request processing is complete. The output is written to the ISAPI output stream (using the ECB.) WriteClient ()) Then the request is complete, and the ISAPI extension is notified of the request processing and releases the ECB. This implementation is very efficient, because. NET class is essentially a very "thin" (thin) wrapper for an efficient, unmanaged ISAPI ECB.

Loading. Net-a little mysterious.

Let's take a step back from here: I skipped. How the NET runtime is loaded. This is where things get a little blurry. I didn't find any documents in the process, and because we were talking about native code, there was no good way to decompile the ISAPI DLL and find it (mount. NET runtime code).

The best guess I can make is when the ISAPI extension accepts the first request that maps to the asp.net extension, the worker process is loaded. NET Runtime. Once the runtime exists, unmanaged code can request a Isapiruntime instance for the specified virtual directory (if it does not exist). Each virtual directory has its own application domain (AppDomain), when an independent application ( Refers to a asp.net program isapiruntime from the START process is always present in the application domain. Instantiation (which should mean isapiruntime instantiation) seems to be done through COM because the interface methods are exposed as COM callable methods.

When the first request for a virtual directory arrives, System.Web.Hosting.AppDomainFactory.Create () function is invoked to create an instance of a isapiruntime. This starts the application's startup process. This call receives the type of the application, the module name and the virtual directory information, This information is asp.net used to create the application domain and to start the ASP.net program for this virtual directory. This HttpRuntime instance is the text of this HttpRuntime derived object, But httpruntime is a sealed class, and the suspected original error is created in a new application domain. Each virtual directory (that is, a asp.net application) hosts a separate application domain. And they are loaded only when a specific ASP.net program is requested. The ISAPI extension manages instances of these httpruntime objects and routes internal requests to the correct HttpRuntime object based on the requested virtual directory.

　　

Figure 4-ISAPI requests the process of using some undocumented classes, interfaces, and calling many factory methods to transfer to the ASP.net HTTP pipeline. Each Web program/virtual directory runs in its own application domain, the caller (an ISAPI DLL) A reference to the Iisapiruntime interface is maintained to trigger the ASP.NET request processing.