ASP.NET网页设计关于在Application_Start中会见Context.Request仓酷云

听03很多师兄说主讲老师杭城方讲课很差就连旁听也没有去了）今天埋怨了一下HttpContext的计划，在Global.asax的Application_Start()中会见Context.Request，会激发“Requestisnotavailableinthiscontext”非常（注：程序运转于IIS集成形式）。
有园友辩驳说在Application_Start()中不该该往会见Context.Request。我对这个辩驳的了解就是HttpApplication还没启动好，还没入手下手正式处置哀求，你就猴急着会见Request干嘛？晓得不，这和列队一样，有个先来后到。先有HttpApplication，然后才有Request。
我厥后想一想，不合错误呀！我们公布一个ASP.NET网站时，并没有先接通电源，按一个启动按钮让HttpApplication启动起来，然后翻开年夜门大呼：“HTTP哀求们，能够出去了”。
实践情形是，公布网站以后，最少有一个哀求，程序才会启动，才会有HttpApplication。明显是先有Request，才会有HttpApplication。
并且前一篇文章中，我们的需求是在Application_Start()中猎取以后Request的URL，Application_Start是由Request而生，有Request的中央就有URL，这个需求通情达理啊！
在程序员的天下，我们必要辩驳，我们也必要对辩驳的对抗。
因而，明天把IIS使用程序池改成传统（Classic）形式，持续在Application_Start()中会见Context.Request。事业呈现了！居然能够一般会见Context.Request，拿到想要的Context.Request.Url.AbsoluteUri。这最少申明了，“在Application_Start()中会见Context.Request”的需求是公道的。假如分歧理，那末在传统Classic形式也不该该能会见，不然就是一个自相冲突的计划。
写代码不是争吵，找到例子证实本人的概念就好了。办理成绩大概找到成绩的缘故原由才是霸道。
在前一篇文章中，我们晓得祸首罪魁是HttpContext的HideRequestResponse属性，再拿出来示众一下：

1. internalboolHideRequestResponse;publicHttpRequestRequest{get{if(this.HideRequestResponse){thrownewHttpException(SR.GetString("Request_not_available"));}returnthis._request;}}

复制代码

既然在IIS集成形式下才会呈现这个非常，那就是在IIS集成形式下，ASP.NETRuntime将HideRequestResponse设置为了true。我们必要找到ASP.NETRuntime在那里干了这个“活动”。这就要借助于.NET天下的侦察新星——ILSpy。
在ILSpy中，选中HttpContext的HideRequestResponse属性，点击“Analyze”，看看谁挪用了HideRequestResponse并修正了它的值，然后一个一个往侦察。。。侦察的历程这里就省略了。。。间接看我们的侦察了局，先看上面的ILSpy截图：

登录/注册后可看大图

既然我们是在Application_Start办法中挪用Context.Request，那我们起首就要晓得Application_Start是在哪实行。实践就是上图所示的FireApplicationOnStart()办法，反编译出来的代码以下：

1. //System.Web.HttpApplicationFactoryprivatevoidFireApplicationOnStart(HttpContextcontext){if(this._onStartMethod!=null){HttpApplicationspecialApplicationInstance=this.GetSpecialApplicationInstance();specialApplicationInstance.ProcessSpecialRequest(context,this._onStartMethod,this._onStartParamCount,this,EventArgs.Empty,null);this.RecycleSpecialApplicationInstance(specialApplicationInstance);}}

复制代码

_onStartMethod就是在Global.asax中界说的Application_Start()办法，从下面的代码中能够看出，_onStartMethod是实践在specialApplicationInstance.ProcessSpecialRequest中被实行的，进进ProcessSpecialRequest看个事实，代码以下（代码已精简，...暗示被省略的代码，重点看白色字体部分）：

1. //System.Web.HttpApplicationinternalvoidProcessSpecialRequest(...){this._context=context;if(HttpRuntime.UseIntegratedPipeline&&this._context!=null){this._context.HideRequestResponse=true;}...using(newHttpContextWrapper(context)){using(newApplicationImpersonationContext()){try{//挪用Application_Start()办法method.Invoke(...)...}catch(Exceptionex){...}finally{...if(HttpRuntime.UseIntegratedPipeline&&this._context!=null){this._context.HideRequestResponse=false;}this._hideRequestResponse=false;...}}}}

复制代码

从下面的白色字体部分能够看出，原形就在这里，当运转于IIS集成形式时，HttpRuntime.UseIntegratedPipeline就即是true，然后HttpContext.HideRequestResponse被设置为true，然后实行Application_Start()中的代码，然后就激发“Requestisnotavailableinthiscontext”非常。
这篇文章只是对“Requestisnotavailableinthiscontext”成绩的进一步探究，找出了成绩产生的详细中央。至于为何微软要这么计划？有无举措在Application_Start()中猎取以后哀求的URL？即便不克不及猎取，有无举措避开这个非常？今朝我们不晓得谜底。
无论谁倒了对双方阵营的粉丝们也是有害无益。