【IT168专稿】

加载.NET-（稍微有点神秘）

    让我们回到之前略过的一个话题：当请求到达时，.NET运行时是如何被加载的。具体在哪里加载的，这是比较模糊的。关于这个处理过程，我没有找到相关的文档，由于我们现在讨论的是本地代码，所以通过反编译ISAPI DLL文件并把它描述出来显得不太容易。

    非常好的猜测是，在ISAPI扩展里，当第一个请求命中一个ASP.NET的映射扩展时，工作线程就会引导.NET运行时启动。一旦运行时存在了，非托管代码就可以为指定的虚拟目录请求一个ISAPIRuntime对象的实例，当然前提条件是，这个实例还不存在。每一个虚拟目录都会拥有一个AppDomain，在ISAPIRuntime存在的AppDomain里，它将引导一个单独的程序启动。由于接口被作为COM可调用的方法暴露，所以实例化操作将发生在COM之上。

    为了创建ISAPIRuntime的实例，当指定虚拟目录的第一个请求到达时，System.Web.Hosting.AppDomainFactory.Create()方法将被调用。这将会启动程序的引导过程。这个方法接收的参数为：类型，模块名以及应用程序的虚拟路径，这些都将被ASP.NET用于创建AppDomain，接着会启动指定虚拟目录的ASP.NET程序。HttpRuntime的根对象将会在一个新的AppDomain里创建。每一个虚拟目录或者ASP.NET程序将寄宿在属于自己的AppDomain里。它们仅仅在有请求到达时启动。ISAPI扩展管理这些HttpRuntime对象的实例，然后基于请求的虚拟路径，把请求路由到正确的应用程序里。

回到运行时

    这个时候已经拥有了一个ISAPIRuntime的活动实例，并且可以在ISAPI扩展里调用。一旦运行时启动并运行起来，ISAPI扩展就可以调用ISAPIRuntime.ProcessRequest()方法了，而这个方法就是进入ASP.NET通道真正的登录点。图1展示了这里的流程。



    图1把ISAPI的请求转到ASP.NET通道需要调用很多没有正式文档的类和接口，以及几个工厂方法。每一个Web程序/虚拟目录都运行在属于自己的AppDomain里。调用者将维护一个IISAPIRuntime接口的代理引用，负责触发ASP.NET的请求处理。记住：ISAPI是多线程的，因此请求可以以多线程的方式穿过AppDomainFactory.Create()返回的对象引用。列表1展现了从IsapiRuntime.ProcessRequest方法反编译得到的代码。这个方法接收一个ISAPI ecb对象和一个服务器类型参数（这个参数用于指定创建何种版本的ISAPIWorkerRequest），这个方法是线程安全的，因此多个ISAPI线程可以同时安全的调用单个返回对象的实例。

    列表 1: ProcessRequest请求进入 .NET的登录点

public int ProcessRequest(IntPtr ecb, int iWRType) 
{ 
// ISAPIWorkerRequest从HttpWorkerRequest 继承，这里创建的是 
// ISAPIWorkerRequest派生类的一个实例 
HttpWorkerRequest request1 = 
ISAPIWorkerRequest.CreateWorkerRequest(ecb,iWRType); 
//得到请求的物理路径 
string text1 = request1.GetAppPathTranslated(); 
//得到AppDomain的物理路径 
string text2 = HttpRuntime.AppDomainAppPathInternal; 
if (((text2 == null) || text1.Equals(".")) || 
(string.Compare(text1, text2, true, 
CultureInfo.InvariantCulture) == 0)) 
{ 
HttpRuntime.ProcessRequest(request1); 
return 0; 
} 
//如果外部请求的AppDomain物理路径和原来AppDomain的路径不同，说明ISAPI维持 
//的AppDomain的引用已经失效了，所以，需要把原来的程序关闭，当有新的请求时，会 
//再次启动程序。 
HttpRuntime.ShutdownAppDomain("Physical path changed from " + 
text2 + " to " + text1); 
return 1; 
}