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:
- Copy the
LaMarvin.Diagnostics.AspNetAssertListener.dll assembly file to the bin subfolder of your ASP.NET application.
- Register the provided trace listener by inserting / modifying the trace listeners section in the
web.config file of your ASP.NET application:
<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.
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.Top 