Asp.net 如何判断Page_PreRender是否已运行？

我正在OnLoad上覆盖的页面中运行一个方法，但仅当Page_PreRender方法已运行时

显然，当我在Page_PreRender中时，我可以翻转一个类级bool并在OnUnload中检查它，但是如果有一种更内在的方法来判断Page_PreRender是否已运行，我想使用它

有什么想法吗

谢谢你的想法

更新：让我稍微重新表述一下我的问题。我正在寻找一个答案，即在页面生命周期中是否有一种简单的方法，可能是由ASP.Net Framework设置的属性，可能是其他一些东西，在页面预呈现运行后与页面预呈现未运行时有所不同

---

我目前正在Page_PreRender中设置一个布尔值来告诉我它是否已运行。这是可行的，但是如果有一种方法可以在不添加额外的布尔检查的情况下完成同样的事情，我不喜欢这个解决方案。如果可能的话，创建在Page_PreRender期间触发的事件与我希望避免的冗余级别相同。

我不确定您的确切意思。根据

PreRender

始终在

Unload

之前运行。如果在此

PreRender

事件中执行一些If条件，并且希望在

Unload

中测试该条件是否满足，则page类上的布尔字段似乎是一个好主意。

我不确定您的确切意思。根据

PreRender

始终在

Unload

之前运行。如果在此

PreRender

事件中执行某些If条件，并且希望在

Unload

中测试该条件是否满足，则page类上的布尔字段似乎是一个好主意。

将trace=true添加到page指令。

将trace=true添加到page指令。

在PreRender中设置布尔字段事件处理程序，然后检查它是否已在卸载事件处理程序中设置。

在PreRender事件处理程序中设置一个布尔字段，然后检查它是否在卸载事件处理程序中设置。

创建一个在预渲染事件中触发的自定义事件。

创建一个在预渲染事件中触发的自定义事件。

我认为没有存储任何类型的状态，因为ASP.NET引擎并不真正需要它，因为它隐式地知道它的状态

使用.NET Reflector搜索时，页面呈现事件似乎是从以下内部System.Web.UI.page方法引发的：

private void ProcessRequestMain(bool includeStagesBeforeAsyncPoint, bool includeStagesAfterAsyncPoint)

你可以看看，这里没有国家的概念。你能得到的唯一信息就是跟踪。如果您有权访问卸载事件，那么您应该有权访问跟踪？或者我错过了什么：-）

由于跟踪实际上是一个数据集隐藏（请参见我的答案：），您可能可以获得信息。但是

---

在生产环境中不建议将trace=true设置为…

我认为没有存储任何类型的状态，因为ASP.NET引擎实际上并不需要它，因为它隐式地知道它的状态

使用.NET Reflector搜索时，页面呈现事件似乎是从以下内部System.Web.UI.page方法引发的：

private void ProcessRequestMain(bool includeStagesBeforeAsyncPoint, bool includeStagesAfterAsyncPoint)

你可以看看，这里没有国家的概念。你能得到的唯一信息就是跟踪。如果您有权访问卸载事件，那么您应该有权访问跟踪？或者我错过了什么：-）

由于跟踪实际上是一个数据集隐藏（请参见我的答案：），您可能可以获得信息。但是 不建议在生产环境中设置trace=true，但…

您（在另一篇文章的评论中）提到，在调用Response.Redirect（）时，您的问题会表现出来，因为它会引发ThreadAbortException，从而导致OnPreRender（）事件未被调用。那么为什么不用这个呢

Response.Redirect("~/SomePage.aspx", false);

您在那里看到的“false”表示页面的执行是否应该立即终止。默认情况下，Response.Redirect（）使用“true”。如果需要运行OnPreRender（）事件，以便OnLoad（）事件具有所需的所有内容，请将其设置为“false”，并确保在调用Response.Redirect（）后跳转到页面的末尾，或者确保在调用Response.Redirect（）后执行的代码可以正常运行

也许您不喜欢使用重载的Response.Redirect（）方法传递“false”，这就是为什么您没有这样做的原因。以下是一些可能会影响你思维的文档：

Microsoft声明“建议为endResponse参数传递false”，因为指定“true”将调用原始请求的HttpResponse.End（）方法，该方法在完成时抛出ThreadAbortException。微软接着说，“这个异常对Web应用程序的性能有不利影响”。请参见此处的“备注”部分：

这是发布的：

结束方法也在我的“从不”上 使用“列表”。最好的方法来阻止 我的请求是打电话 HttpApplication.CompleteRequest。这个 End方法之所以存在，是因为我们 试图与经典兼容 ASP在1.0发布时。经典 ASP有一个Response.End方法 终止ASP 剧本为了模仿这种行为， ASP.NET的End方法试图引发 线程异常。如果这是 如果成功，调用线程将被删除 流产（非常昂贵，对健康不好） 性能），管道将 跳转到EndRequest事件。 ThreadAbortException，如果 当然，成功意味着 线程在调用任何 更多代码，所以调用End意味着 之后不会调用任何代码。 如果End方法无法提升 一个线程异常，它将 而是将响应字节刷新到 客户端，但它会这样做 同步进行，这对我们来说真的不好 性能，以及当用户代码 在End执行完成后 管道向前跳转到EndRequest 通知。将字节写入 客户端是一个非常昂贵的操作， 特别是如果克莱

if (HttpContext.Current.Response.IsRequestBeingRedirected != true)
{
    //You're custom OnUnload() logic here.
}

Server.Execute("~/SomePage.aspx", false);
return;