asp.net确认对话框_在ASP.NET或Trace.Fail中防止服务器端对话框被认为有害

asp.net确认对话框

Dialogs on the server-side? What is this nonsense of which you speak? Are you insane? Sadly no.

服务器端的对话框？ 您说的这胡话是什么？ 你疯了？ 可悲的是没有。

Back in the day, if you ran a VB6 COM DLL under Classic ASP, or as I like to call it "Poopy-SP," and you forgot to set "Unattended Execution" and "Retain in Memory" you could get yourself into a pickle if an error in the application caused a dialogbox or messagebox to pop up on the Server-side, just waiting for some poor schmuck to click "OK."

回顾过去，如果您在经典ASP下运行VB6 COM DLL，或者我喜欢将其称为“ Poopy-SP”，而您却忘记设置“无人参与执行”和“保留在内存中”，则可能会陷入困境。如果应用程序中的错误导致在服务器端弹出对话框或消息框，则请选择“腌制”，只需等待一些糟糕的选项即可单击“确定”。

Recently I got an email that a high-powered blogger was seeing Dialog Boxes on his hosted instance of DasBlog while running under ASP.NET 2.0. These dialogs would hang the thread they were on, and hang IIS until they were dismissed. Shocked he and I were to say the least as "that ain't supposed to happen."

最近，我收到一封电子邮件，内容是功能强大的博客作者在ASP.NET 2.0下运行时，在其托管的DasBlog实例上看到对话框。 这些对话框将挂起它们所在的线程，并挂起IIS，直到将其关闭。 令我震惊的他和我至少要说“那不应该发生的”。

I suggested that he disable JIT Debugging in his registry. He tried it and indicated that he was getting a full stack trace inside the message box. Since the JIT Debugging Dialog doesn't look like that, I figured that wasn't the problem.

我建议他在注册表中禁用JIT调试。 他尝试了一下，并指出他正在消息框中获得完整的堆栈跟踪。 由于“ JIT调试对话框”看起来并非如此，因此我认为这不是问题。

I spoke to some folks at MSFT who said that if there were unhandled exceptions being thrown from DasBlog, how they'd be presented would be controlled via the legacyUnhandledExceptionPolicy setting in his web.config like this (we don't have any unhandled exceptions, BTW, there's 'global' exception handlers in two places):

我曾与MSFT的一些人交谈，他们说，如果DasBlog抛出了未处理的异常，将如何通过它们在web.config中的legacyUnhandledExceptionPolicy设置来控制如何呈现这些异常(我们没有任何未处理的异常，顺便说一句，在两个地方有“全局”异常处理程序)：

<configuration>
  <runtime>
    <legacyUnhandledExceptionPolicy enabled="true" />
  </runtime>
</configuration>

<配置> <运行时> <legacyUnhandledExceptionPolicy enabled =“ true” /> </运行时> </ configuration>

This tells the CLR to act more like .NET 1.1 in this respect as the behavior for unhandled exceptions has changed in 2.0 (MSDN Mag Article here and MSDN Topic here).

这告诉CLR在这方面的行为更像.NET 1.1，因为未处理异常的行为在2.0中有所更改(此处为MSDN Mag文章，此处为MSDN主题)。

This "solution" smelled fishy to me, didn't seem like a good idea, and ultimately didn't solve his problem.

这个“解决方案”对我来说很腥，似乎不是一个好主意，最终没有解决他的问题。

He then indicated that he was seeing errors in our SharedBasePageErrorHandler, which made sense to me as we handle all Page-level exceptions there.

然后，他指出他在我们的SharedBasePageErrorHandler中看到错误，这对我们来说很有意义，因为我们在那里处理所有页面级异常。

private void SharedBasePageErrorHandler(object sender, EventArgs e )
{
    Exception pageException = Server.GetLastError();
    try
    {
        loggingService.AddEvent(
            new EventDataItem(EventCodes.Error,
            pageException.ToString().Replace("\n","<br>"),
            this.Page.Request.Url.ToString()));
        System.Diagnostics.Trace.Fail(this.Context.Error.Message);
    }
    catch
    {
    }
}

私人void SharedBasePageErrorHandler(object sender，EventArgs e) { 异常pageException = Server.GetLastError(); 尝试{ loggingService.AddEvent( 新的EventDataItem(EventCodes.Error， pageException.ToString()。Replace(“ \ n”，“ <br>”)， this.Page.Request.Url.ToString())); System.Diagnostics.Trace.Fail(this.Context.Error.Message); } 抓住{ } }

Seems pretty straightforward, and his stuff WAS getting logged indicating that the LoggingService.AddEvent was working fine.

看起来非常简单，并且他的东西被记录下来，表明LoggingService.AddEvent运行正常。

What about this System.Diagnostics.Trace.Fail call, though? Seems harmless, but it's the only other thing in there and it would explain where the stack trace was coming from - it's inside of this.Context.Error.Message.

但是，该System.Diagnostics.Trace.Fail调用又如何呢？ 看起来是无害的，但这是其中唯一的另一件事，它可以解释堆栈跟踪的来源-它位于this.Context.Error.Message内部。

There was a problem back in the day with Trace.Fail or Debug.Fail locking up the ASP.NET Worker Process.

有一个问题，早在与Trace.Fail或Debug.Fail锁定了ASP.NET工作进程的一天。

If you reflector into the implementation of the DefaultTraceListener in the .NET Framework you'll see a call to AssertWrapper.ShowAssert (that should only happen if AssertUIEnabled is true and UI Permissions are available.) That must be the case in our blogger friend's situation.

如果您反映了.NET Framework中DefaultTraceListener的实现，您将看到对AssertWrapper.ShowAssert的调用(仅在AssertUIEnabled为true且UI权限可用时才发生。)在我们博客作者的情况下一定是这种情况。

public override void Fail(string message, string detailMessage)
{
      string text1;
      StackTrace trace1 = new StackTrace(true);
      int num1 = 0;
      bool flag1 = DefaultTraceListener.UiPermission;
      try
      {
            text1 = this.StackTraceToString(trace1, num1, trace1.FrameCount - 1);
      }
      catch
      {
            text1 = "";
      }
      this.WriteAssert(text1, message, detailMessage);
      if (this.AssertUiEnabled && flag1)
      {
            AssertWrapper.ShowAssert(text1, trace1.GetFrame(num1), message, detailMessage);
      }
}

公共重写无效失败(字符串消息，字符串detailMessage) { 字符串text1; StackTrace trace1 =新的StackTrace(true); int num1 = 0; bool flag1 = DefaultTraceListener.UiPermission; 尝试{ text1 = this.StackTraceToString(trace1，num1，trace1.FrameCount-1); } 抓住{ text1 =“”; } this.WriteAssert(text1，message，detailMessage); 如果(this.AssertUiEnabled && flag1) { AssertWrapper.ShowAssert(text1，trace1.GetFrame(num1)，message，detailMessage); } }

Assuming those things are true and ShowAssert does get called, interally the AssertWrapper.ShowAssert calls SafeNativeMethods.MessageBox only if the user is in an interactive mode. It's possible that MB_SERVICE_NOTIFICATION isn't being passed into the MessageBox indicating that it's a non-interactive service who is throwing the box.

假设这些情况是正确的，并且ShowAssert确实被调用，则只有当用户处于交互方式时，AssertWrapper.ShowAssert才会内部调用SafeNativeMethods.MessageBox。 MB_SERVICE_NOTIFICATION可能没有传递到MessageBox中，表明它是抛出该框的非交互式服务。

Setting this option in the web.config (or machine.config) works around the issue by not even getting into AssertWrapper.

在web.config(或machine.config)中设置此选项可以解决该问题，甚至不需要进入AssertWrapper。

<configuration>
   <system.diagnostics>
      <assert assertuienabled="false" logfilename="c:\log.txt"/>
   </system.diagnostics>
</configuration>

<配置> <system.diagnostics> <assert assertuienabled =“ false” logfilename =“ c：\ log.txt” /> </system.diagnostics> </ configuration>

This looks like a bug in ASP.NET 2.0, but we'll see.

这看起来像是ASP.NET 2.0中的错误，但我们会看到。

The workarounds are:

解决方法是：

• Don't use Trace.Fail()
  不要使用Trace.Fail()

or

要么

• Set AssertUIEnabled="false" in your web.config.
  在您的web.config中设置AssertUIEnabled =“ false”。

The strange part about this is why it's seen on some systems and not others.

奇怪的是，为什么它在某些系统而不是其他系统上可见。

翻译自: https://www.hanselman.com/blog/preventing-dialogs-on-the-serverside-in-aspnet-or-tracefail-considered-harmful

asp.net确认对话框