.NET 1.1中预编译ASP.NET页面实现原理浅析 [1] 自动预编译机制浅析

类别:.NET开发 点击:0 评论:0 推荐:


http://flier_lu.blogone.net?id=1544105

.NET 1.1中预编译ASP.NET页面实现原理浅析

    MS在发布ASP.NET时的一大功能特性是,与ASP和PHP等脚本语言不同,ASP.NET实际上是一种编译型的快速网页开发环境。这使得ASP.NET在具有开发和修改的简便性的同时,不会负担效率方面的损失。实现上ASP.NET与JSP的思路类似,引擎在第一次使用一个页面之前,会将之编译成一个类,自动生成Assembly并载入执行。
    而通过《在WinForm程序中嵌入ASP.NET》一文中我们可以了解到,ASP.NET引擎实际上是可以无需通过IIS等Web服务器调用而被使用的,这就使得手工预编译ASP.NET页面成为可能。实际上这个需求是普遍存在的,早在ASP时代就层有第三方产品支持将ASP页面编译成二进制程序,以提高执行效率和保障代码安全性,而将伴随Whidbey发布的ASP.NET 2.0更是直接内置了预编译ASP.NET页面的功能。

    实际上网上早就有人讨论过在ASP.NET 1.1中模拟预编译特性的实现方法,例如以下两篇文章

    Pre-Compiling ASP.NET Web Pages
    Pre-Compile ASPX pages in .NET 1.1

    其思路基本上都是遍历所有需要预编译的页面文件,然后通过模拟Web页面请求的方式,触发ASP.NET引擎的自动预编译机制。这样做的好处是完全模拟真实情况,无需了解ASP.NET引擎的实现原理;但同时也会受到诸多限制,如预编译结果不透明,无法脱离原始ASP.NET页面文件使用等等,而且无法使我们从原理上理解预编译特性的实现。

    下面我将分三到四个小节,简要讨论 ASP.NET 自动编译机制的实现、ASP.NET 页面文件编译的实现以及如何在ASP.NET 1.1中实现手动预编译页面和相应分发机制。

[1] 自动预编译机制浅析

    本节我们将详细分析讨论.NET 1.1中,ASP.NET引擎内部实现自动页面预编译的原理。

    首先,我们所说的ASP.NET页面实际上主要分为四类:

    1.Web 应用程序文件    Global.asax
    2.Web 页面文件        *.aspx
    3.用户自定义控件文件  *.ascx
    4.Web 服务程序文件    *.asmx

    Web 应用程序文件对于每个Web 应用程序来说是可选唯一的,用来处理ASP.NET应用程序一级的事件,并将被预编译为一个System.Web.HttpApplication类的子类;
    Web 页面文件是普通的ASP.NET页面,处理特定页面的事件,将被预编译为一个System.Web.UI.Page类的子类;
    用户自定义控件文件是特殊的ASP.NET页面,处理控件自身的事件,将被预编译为一个System.Web.UI.UserControl类的子类;
    Web 服务程序文件则是与前三者不太相同的一种特殊页面文件,暂时不予讨论。

    然后,前三种ASP.NET文件的编译时机也不完全相同。Web 应用程序文件在此 Web 应用程序文件第一次被使用时自动编译;Web 页面文件在此Web页面第一次被使用时自动编译,实际上是调用 HttpRuntime.ProcessRequest 函数触发预编译;用户自定义控件文件则在其第一次被 Web 页面使用的时候自动编译,实际上是调用 Page.LoadControl 函数触发预编译。

    在了解了以上这些基本知识后,我们来详细分析一下自动预编译的实现机制。

    HttpRuntime.ProcessRequest 函数是处理Web页面请求的调用发起者,伪代码如下:

以下为引用:

public static void HttpRuntime.ProcessRequest(HttpWorkerRequest wr)
{
  // 检查当前调用者有没有作为ASP.NET宿主(Host)的权限
  InternalSecurityPermissions.AspNetHostingPermissionLevelMedium.Demand();

  if(wr == null)
  {
    throw new ArgumentNullException("custom");
  }

  RequestQueue queue = HttpRuntime._theRuntime._requestQueue;

  if(queue != null)
  {
    // 将参数中的Web页面请求放入请求队列中
    // 并从队列中使用FIFO策略获取一个页面请求
    wr = queue.GetRequestToExecute(wr);
  }

  if(wr != null)
  {
    // 更新性能计数器
    HttpRuntime.CalculateWaitTimeAndUpdatePerfCounter(wr);
    // 实际完成页面请求工作
    HttpRuntime.ProcessRequestNow(wr);
  }
}


    HttpRuntime.ProcessRequestNow函数则直接调用缺省HttpRuntime实例的ProcessRequestInternal函数完成实际页面请求工作,伪代码如下:
以下为引用:

internal static void HttpRuntime.ProcessRequestNow(HttpWorkerRequest wr)
{
  HttpRuntime._theRuntime.ProcessRequestInternal(wr);
}


    HttpRuntime.ProcessRequestInternal函数逻辑稍微复杂一些,大致可分为四个部分。

    首先检查当前HttpRuntime实例是否第一次被调用,如果是第一次调用则通过FirstRequestInit函数初始化;
    接着调用HttpResponse.InitResponseWriter函数初始化页面请求的返回对象HttpWorkerRequest.Response;
    然后调用HttpApplicationFactory.GetApplicationInstance函数获取当前 Web 应用程序实例;
    最后使用Web应用程序实例完成实际的页面请求工作。

    伪代码如下:
以下为引用:

private void HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)
{
  // 构造 HTTP 调用上下文对象
  HttpContext ctxt = new HttpContext(wr, 0);

  // 设置发送结束异步回调函数
  wr.SetEndOfSendNotification(this._asyncEndOfSendCallback, ctxt);

  // 更新请求计数器
  Interlocked.Increment(&(this._activeRequestCount));

  try
  {
    // 检查当前HttpRuntime实例是否第一次被调用
    if(this._beforeFirstRequest)
    {
      lock(this)
      {
        // 使用 Double-Checked 模式 避免冗余锁定
        if(this._beforeFirstRequest)
        {
          this._firstRequestStartTime = DateTime.UtcNow;
          this.FirstRequestInit(ctxt); // 初始化当前 HttpRuntime 运行时环境
          this._beforeFirstRequest = false;
        }
      }
    }

    // 根据配置文件设置,扮演具有较高特权的角色
    ctxt.Impersonation.Start(true, false);
    try
    {
      // 初始化页面请求的返回对象
      ctxt.Response.InitResponseWriter();
    }
    finally
    {
      ctxt.Impersonation.Stop();
    }

    // 获取当前 Web 应用程序实例
    IHttpHandler handler = HttpApplicationFactory.GetApplicationInstance(ctxt);

    if (handler == null)
    {
      throw new HttpException(HttpRuntime.FormatResourceString("Unable_create_app_object"));
    }

    // 使用Web应用程序实例完成实际的页面请求工作
    if((handler as IHttpAsyncHandler) != null)
    {
      IHttpAsyncHandler asyncHandler = ((IHttpAsyncHandler) handler);
      ctxt.AsyncAppHandler = asyncHandler;
      // 使用异步处理机制
      asyncHandler.BeginProcessRequest(ctxt, this._handlerCompletionCallback, ctxt);
    }
    else
    {
      handler.ProcessRequest(ctxt);
      this.FinishRequest(ctxt.WorkerRequest, ctxt, null);
    }
  }
  catch(Exception E)
  {
    ctxt.Response.InitResponseWriter();
    this.FinishRequest(wr, ctxt, E);
  }
}


    HttpRuntime.ProcessRequestInternal函数中,涉及到文件预编译的有两部分:一是获取当前 Web 应用程序实例时,会根据情况自动判断是否预编译Web 应用程序文件;二是在完成实际页面请求时,会在第一次使用某个页面时触发预编译行为。

    首先来看看对 Web 应用程序文件的处理。

    HttpRuntime.ProcessRequestInternal函数中调用了HttpApplicationFactory.GetApplicationInstance函数获取当前 Web 应用程序实例。System.Web.HttpApplicationFactory是一个内部类,用以实现对多个Web应用程序实例的管理和缓存。GetApplicationInstance函数返回的是一个IHttpHandler接口,提供IHttpHandler.ProcessRequest函数用于其后对Web页面文件的处理。伪代码如下:
以下为引用:

internal static IHttpHandler HttpApplicationFactory.GetApplicationInstance(HttpContext ctxt)
{
  // 定制应用程序
  if(HttpApplicationFactory._customApplication != null)
  {
    return HttpApplicationFactory._customApplication;
  }
  // 调试请求
  if(HttpDebugHandler.IsDebuggingRequest(ctxt))
  {
    return new HttpDebugHandler();
  }

  // 判断是否需要初始化当前 HttpApplicationFactory 实例
  if(!HttpApplicationFactory._theApplicationFactory._inited)
  {
    HttpApplicationFactory factory = HttpApplicationFactory._theApplicationFactory;

    lock(HttpApplicationFactory._theApplicationFactory);
    {
      // 使用 Double-Checked 模式 避免冗余锁定
      if(!HttpApplicationFactory._theApplicationFactory._inited)
      {
        // 初始化当前 HttpApplicationFactory 实例
        HttpApplicationFactory._theApplicationFactory.Init(ctxt);
        HttpApplicationFactory._theApplicationFactory._inited = true;
      }
    }
  }

  // 获取 Web 应用程序实例
  return HttpApplicationFactory._theApplicationFactory.GetNormalApplicationInstance(ctxt);
}


    在处理特殊情况和可能的实例初始化之后,调用HttpApplicationFactory.GetNormalApplicationInstance函数完成获取Web应用程序实例的实际功能,伪代码如下:
以下为引用:

private HttpApplication HttpApplicationFactory.GetNormalApplicationInstance(HttpContext context)
{
  HttpApplication app = null;

  // 尝试从已施放的 Web 应用程序实例队列中获取
  lock(this._freeList)
  {
    if(this._numFreeAppInstances > 0)
    {
      app = (HttpApplication)this._freeList.Pop();
      this._numFreeAppInstances--;
    }
  }

  if(app == null)
  {
    // 构造新的 Web 应用程序实例
  app = (HttpApplication)System.Web.HttpRuntime.CreateNonPublicInstance(this._theApplicationType);

  // 初始化 Web 应用程序实例
app.InitInternal(context, this._state, this._eventHandlerMethods);
  }

  return app;
}


    构造新的 Web 应用程序实例的代码很简单,实际上就是对Activator.CreateInstance函数的简单包装,伪代码如下:
以下为引用:

internal static object HttpRuntime.CreateNonPublicInstance(Type type, object[] args)
{
  return Activator.CreateInstance(type, BindingFlags.CreateInstance | BindingFlags.Instance |
    BindingFlags.NonPublic | BindingFlags.Public, null, args, null);
}

internal static object HttpRuntime.CreateNonPublicInstance(Type type)
{
  return HttpRuntime.CreateNonPublicInstance(type, null);
}


    至此一个 Web 应用程序实例就被完整构造出来,再经过InitInternal函数的初始化,就可以开始实际页面处理工作了。而HttpApplicationFactory实例的_theApplicationType类型,则是结果预编译后的Global.asax类。实际的预编译工作在HttpApplicationFactory.Init函数中完成,伪代码如下:
以下为引用:

private void HttpApplicationFactory.Init(HttpContext ctxt)
{
if(HttpApplicationFactory._customApplication != null)
return;

  using(HttpContextWrapper wrapper = new HttpContextWrapper(ctxt))
{
  ctxt.Impersonation.Start(true, true);
  try
  {
    try
    {
      this._appFilename = HttpApplicationFactory.GetApplicationFile(ctxt);
  this.CompileApplication(ctxt);
  this.SetupChangesMonitor();
    }
    finally
    {
      ctxt.Impersonation.Stop();
    }
  }
  catch(Object)
  {
  }
  this.FireApplicationOnStart(ctxt);
}
}


    GetApplicationFile函数返回Web请求物理目录下的global.asax文件路径;CompileApplication函数则根据此文件是否存在,判断是预编译之并载入编译后类型,还是直接返回缺省的HttpApplication类型,伪代码如下:
以下为引用:

internal static string HttpApplicationFactory.GetApplicationFile(HttpContext ctxt)
{
  return Path.Combine(ctxt.Request.PhysicalApplicationPath, "global.asax");
}

private void HttpApplicationFactory.CompileApplication(HttpContext ctxt)
{
  if(FileUtil.FileExists(this._appFilename))
  {
    ApplicationFileParser parser;

    // 获取编译后的 Web 应用程序类型
    this._theApplicationType = ApplicationFileParser.GetCompiledApplicationType(this._appFilename, context, out parser);
    this._state = new HttpApplicationState(parser1.ApplicationObjects, parser.SessionObjects);
    this._fileDependencies = parser.SourceDependencies;
  }
  else
  {
    this._theApplicationType = typeof(HttpApplication);
    this._state = new HttpApplicationState();
  }
  this.ReflectOnApplicationType();
}


    分析到这里我们可以发现,内部类型System.Web.UI.ApplicationFileParser的GetCompiledApplicationType函数是实际上进行Web应用程序编译工作的地方。但现在我们暂且打住,等下一节分析编译过程时再详细解说。 :)

    然后我们看看对 Web 页面文件的处理。

    在前面分析HttpRuntime.ProcessRequestInternal函数时我们曾了解到,在获得了Web应用程序实例后,会使用此实例的IHttpAsyncHandler接口或IHttpHandler接口,完成实际的页面请求工作。而无论有否Global.asax文件,最终返回的Web应用程序实例都是一个HttpApplication类或其子类的实例,其实现了IHttpAsyncHandler接口,支持异步的Web页面请求工作。对此接口的处理伪代码如下:
以下为引用:

private void HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)
{
  ...

  // 使用Web应用程序实例完成实际的页面请求工作
  if((handler as IHttpAsyncHandler) != null)
  {
    IHttpAsyncHandler asyncHandler = ((IHttpAsyncHandler) handler);
    ctxt.AsyncAppHandler = asyncHandler;
    // 使用异步处理机制
    asyncHandler.BeginProcessRequest(ctxt, this._handlerCompletionCallback, ctxt);
  }
  else
  {
    handler.ProcessRequest(ctxt);
    this.FinishRequest(ctxt.WorkerRequest, ctxt, null);
  }

  ...
}


    HttpRuntime.ProcessRequestInternal函数通过调用HttpApplication.IHttpAsyncHandler.BeginProcessRequest函数开始页面请求工作。而HttpApplication实际上根本不支持同步形式的IHttpHandler接口,伪代码如下:
以下为引用:

void HttpApplication.ProcessRequest(System.Web.HttpContext context)
{
  throw new HttpException(HttpRuntime.FormatResourceString("Sync_not_supported"));
}

bool HttpApplication.get_IsReusable()
{
  return true;
}


    而在HttpApplication.IHttpAsyncHandler.BeginProcessRequest函数中,将完成非常复杂的异步调用后台处理操作,这儿就不多罗嗦了,等有机会写篇文章专门讨论一下ASP.NET中的异步操作再说。而其最终调用还是使用System.Web.UI.PageParser对需要处理的Web页面进行解析和编译。

    最后我们看看对用户自定义控件文件的处理。

    Page类的LoadControl函数实际上是在抽象类TemplateControl中实现的,伪代码如下:
以下为引用:

public Control LoadControl(string virtualPath)
{
  virtualPath = UrlPath.Combine(base.TemplateSourceDirectory, virtualPath);
  Type type = UserControlParser.GetCompiledUserControlType(virtualPath, null, base.Context);
  return this.LoadControl(type1);
}


    实际的用户自定义控件预编译操作还是在UserControlParser类中完成的。

    至此,在这一节中我们已经大致了解了ASP.NET自动预编译的实现原理,以及在什么时候对页面文件进行预编译。下一节我们将详细分析ApplicationFileParser、PageParser和UserControlParser,了解ASP.NET是如何对页面文件进行预编译的。

本文地址:http://com.8s8s.com/it/it44930.htm