|
An ordinary VB developer shares his own successes and failures |
|
| Home News Articles Resources Tips Downloads About me | ||
Failed assertion message box for ASP.NETDisplay Debug.Assert message boxes while debugging ASP.NET applications.Using assertions deliberately is a good programming practice... well, but only as long as the assertion is annoying enough that it is easier to fix its cause than to ignore it. You might not agree, but this was my real-world experience with an ASP.NET application I've "inherited" recently.The problem with the System.Diagnostics.Debug.Assert method under ASP.NET is
that when the assertion fails, no message box is displayed. Instead, the assertion
message and the stack trace are written into the VS.NET Output window, where it is too
easy to ignore them (for some categories of developers, that is).
Because I had to spend several hours analyzing and fixing an error that could be easily avoided provided the original developer didn't ignore failed assertions, I've started to think about how to make assertions under ASP.NET more 'thorny'. My requirements were as follows: A failed assertion in an ASP.NET application should display a message box just like the one displayed for WinForms and Console applications. Of course, the message box should be displayed only while debugging the application on local machine (i.e. the web site and the browser run on the same machine). In other circumstances, the assertion mechanism should be 'quiet'. I've borrowed some ideas and code here and there and I've come up with an implementation that satisfies the above requirements. The usage is simple:
<system.diagnostics>
<trace>
<listeners>
<add name="AspNetAssertListener"
type="LaMarvin.Diagnostics.AspNetAssertListener,LaMarvin.Diagnostics.AspNetAssertListener" />
</listeners>
</trace>
</system.diagnostics>
That's it. The next time your ASP.NET code encounters a failed assertion running locally and
under debugger, a nice, annoying message box is displayed like this:
(click to enlarge) If you click the Abort button, the ASP.NET worker process (aspnet_wp.exe) will be terminated, resulting in the "Server Application Unavailable" error, so in general, you should avoid using this option. If you click the Retry button, you'll break into the debugger right at the Debug.Assert statement that failed.
If you click Cancel, the execution will continue effectively ignoring the assertion. You can download the code here. Here are the sources of inspiration that helped me implement the LaMarvin.Diagnostics.AspNetAssertListener assembly:
http://www.codeproject.com/aspnet/debuglistener.asp#xx399004xx - An implementation of a TraceListener that rewrites the ASP.NET Response output buffer with javascript.alert code. http://www.eggheadcafe.com/articles/20030402.asp - C# implementation that uses the System.Windows.Forms.MessageBox with the
MessageBoxOptions.DefaultDesktopOnly flag.
(The LaMarvin.Diagnostics.AspNetAssertListener uses this approach but it doesn't reference
the System.Windows.Forms assembly. Instead, I'm using Interop to invoke the
MessageBox API directly - see the code for details.)
http://msdn.microsoft.com/msdnmag/issues/01/10/bugslayer/ - John Robbins' article; although somewhat dated, it is a very comprehensive treatment of assertions and tracing under ASP.NET. Unfortunately, without a message box :-( http://www.c-sharpcorner.com/Code/2003/Dec/DebugAssertInASPDotNet.asp - A TraceListener descendant that just breaks into debugger depending on a custom trace switch. © Palo Mraz, Monday, September 20, 2004 |
||
|
|
||
| ©2003-2008 Palo Mraz. All Rights Reserved. See my 'new browser window' policy | ||