Click here to Skip to main content
Click here to Skip to main content

Automatically break into code when calling Debug.Assert in ASP.NET and Web Services

, 22 Dec 2003
Rate this:
Please Sign up or sign in to vote.
Automatically break into code when calling Debug.Assert in ASP.NET and Web Services

Introduction

Debug.Assert is one of the greatest tools for developers to use for creating solid, bug free code. The problem with using Debug.Assert lies when you are writing an ASP.Net web site or Web Service. By default with these types of projects, when an Assertion fails, Visual Studio will log the Assertion message to the Debug Output window. But that’s it, no other type of notification that the Assertion failed. ASP.Net and Web Services do not have any built in ability to break into debug mode when an Assertion fails. This sample creates a dll that once referenced by your ASP.Net or Web Service app, just adding a small block of xml into your web.config file will cause the debugger to automatically break into your code.

A Note on Assertions and this article

In this article, I’m making the assumption that the reader knows the how’s, whys, and when’s to using Debug.Assert. Unfortunately, Assertions are a commonly misunderstood and misused debugging tool. To find out more on the Assertion, ready chapter 3 of John Robbins ‘Debugging Applications for Microsoft .Net and Microsoft Windows’. This book is an amazing resource on power debugging. Also read everything MSDN has to say about the System.Diagnostic namespace.

Assertions in WinForms and Console Applications

Debug.Assert is one of the greatest tools for developers to use for creating solid, bug free code. When an Assertion fails in a WinForm application, by default, you get a message box (see Figure 1) that shows the Assertion message, the stack trace where the Assertion failed, and an option to break into debug mode on the line of code after the Assertion. If you click the Retry button, the debugger will kick in and let you inspect the values that failed the Assertion.

Figure 1

Enter ASP.Net and Web Services

The problem with using Debug.Assert lies when you are writing an ASP.Net web site or Web Service. By default with these types of projects, when an Assertion fails, Visual Studio will log the Assertion message to the Debut Output window. But that’s it, no other type of notification that the Assertion failed. ASP.Net and Web Services do not have any built in ability to break into debug mode when an Assertion fails.

A brief overview of TraceListener Objects

A TraceListener class is a class that handles message output for Debug and Trace classes (located in the System.Diagnostic namespace). The Debug and Trace classes have a static collection object called Listeners, which holds a list of TraceListener objects. By default this collection holds only one TraceListener object, the DefaultTraceListener. The .Net Framework also includes a TextWriterTraceListener and an EventLogTraceListener. When you call Debug.Assert or Debug.WriteLine, the runtime loops through each TraceListener in the Debug.Listeners collection and sends the each one the message that you provided. So if you added both the TextWriterTraceListener and the EventLogTraceListener objects to Debug.Listeners, you’ll get the Assertion message sent to Visual Studios debug output window, the event viewer, and a text file (You must configure each listener via their constructor, but that is outside the scope of this example).

So what does this have to do with breaking on an Assert?

The solution to this problem is a cool, but extremely simple one. Create your own custom TraceListener object that will handle breaking into the code. This isn’t exactly what the TraceListener class was designed for, but it suites our needs here very nicely. To do this, create a new library project in Visual Studio and rename the default class to ASPNetDebugAssert, and have this class inherit from System.Diagnostics.TraceListener. Then override the 4 Write() and WriteLine() methods of the TraceListener base class. In each one of these overridden methods, make a call to BreakInCode(). The code for BreakInCode is listed below.

private void BreakInCode()
{
    BooleanSwitch assertSwitch = new BooleanSwitch("BreakOnAssert", "");

    if (assertSwitch.Enabled)
    {
        if (Debugger.IsAttached)
            Debugger.Break();
        else
            Debugger.Launch();
    }
}

This method is the workhorse of the dll (albeit, a very small workhorse indeed!). It first creates a BooleanSwitch object based on a value we’ll later put in the ASP.Net or Web Service’s web.config file. If the BooleanSwitch is enabled it checks to see if a debugger is attached. If the debugger is attached to the running process, the code calls Debugger.Break() which will cause Visual Studio to break on the very next line after the Debug.Assert call. If the debugger is not attached to the running process, the code will try to launch the debugger.

And that’s all there is to it…well, almost. When your code calls Debug.Assert() in an ASP.Net application and the Assertion fails, the Debug class will loop through each listener in its collection and call the Write() method on each one. When it calls our custom TraceListener class, the debugger is told to break…and Shazam!!!…the debugger will kick in and stop on the next line of code in your ASP.Net application.

Configuring your ASPNetDebugAssert listener in the web.config

We’re not quite done here. In order for the BreakInCode() method to work correctly, we need to put a few things into the web.config file. The following block of xml is what you’ll have to add.

<system.diagnostics>
    <switches>        
        <add name="BreakOnAssert" value="1" />
    </switches>
    <trace autoflush="true" indentsize="0">
        <listeners>
            <add name="MyListener" 
   type="ASPNetDebugAssertion.ASPNetDebugAssert,ASPNetDebugAssertion"  />
        </listeners>
    </trace>
</system.diagnostics>

The first thing in here is a definition for our BooleanSwitch. The <switches><add> element turns the BooleanSwitch on or off (enabled or disabled). Setting the value attribute to 0 will disable the switch and 1 will enable it (in the case of our custom dll, 1 will cause the debugger to break, 0 will not cause the debugger to break).

The second item in this xml block is the <trace> element. With this element, we can add and remove TraceListener objects to the Debug.Listeners collection without having to recompile our code. I’ll leave it up to you to read up on these web.config elements in MSDN, but it should be obvious that this example adds our custom ASPNetDebugAssert TraceListener to the Listeners collection.

So how do I use this?

The final piece to this example is actually calling Debug.Assert in an ASP.Net application. There are a few things we have to do to piece this all together. First, compile your ASPNetDebugAssertion library in Release build mode. Then, in your ASP.Net or Web Service project, add a reference to the release version of the dll. (Note: If you compile the ASPNetDebugAssertion dll under debug mode, the debugger will use the debug symbols of our dll and break on the line right after Debugger.Break is called.). Next, copy and paste the web.config xml block listed above into your ASP.Net project’s web.config file. Be sure to paste it inside the <configuration> element, but OUTSIDE of the <system.web> element.

Once this is done, your project is setup and ready to Assert! Somewhere in the code behind of one of your web forms, add the following lines of code.

private void Button1_Click(object sender, System.EventArgs e)
{
    Debug.Assert(sender == null, "sender obj is null");
    
    string assertTest = "Hey, this worked";
    
    this.TextBox1.Text = assertTest;
}

When the application is first started, the Debug class will check the web.config file and look to see if any TraceListeners should be added to its Listeners collection. Once Debug.Assert is called, it will send “The assertion worked!!” to each TraceListener, including ours. When our dll is called, the BreakInCode() method will do its work and the debugger will break on the line of code immediately following the Debug.Assert. And that’s it!!! You now get debugger breaking when you use Assertions, just like you do (almost) with a WinForm application. If you want to turn the break mode off, just change the BooleanSwitch definition in the web.config to “0”.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

jconwell

United States United States
I have been a professional developer since 1996. My experience comes from many different industries; Data Mining Software, Consulting, E-Commerce, Wholesale Operations, Clinical Software, Insurance, Energy.
 
I started programming in the military, trying to find better ways to analyze database data, eventually automating my entire job. Later, in college, I automated my way out of another job. This gave me the great idea to switch majors to the only thing that seemed natural…Programming!
Follow on   Twitter

Comments and Discussions

 
GeneralMy vote of 1 Pinmemberkhanyasir27-Dec-11 20:44 
GeneralASP.NET under Windows 7 Pinmemberdogeth15-Aug-11 18:10 
NewsASP.NET 2.0 -Debug.Assert works as expected PinmemberMichael Freidgeim29-Dec-05 18:41 
GeneralRe: ASP.NET 2.0 -Debug.Assert works as expected Pinmemberjconwell15-Aug-06 13:14 
Generalexception PinmemberTyrantMikey26-Aug-05 5:19 
Generalsimple way PinmemberRed Forks19-Aug-05 18:37 
not use Debug.XXXX
create your know DebugUtil class
in your DebugUtil.XXXX() raise an exception instead.
 
Of couse, add [Conditional("DEBUG")] to your methods, so no configure needed, run as Debug, with Debug checks, run as Release, without Deubg checkes.
 
Debug.XXX() methods() not use exception, it more like a filter. It work well in WinForms applications, but not Asp.Net, and other Services apps. It relies on its runtime enviroment, I think use exception is more robust if you want your class lib with robust Parameter check or other debug checks.
 
I have an article like yours http://www.codeproject.com/aspnet/debuglistener.asp[^].
now I don't use it again. I use exception instead.
GeneralCode breaks in for Write statements -FIX PinmemberMichael Freidgeim12-Aug-04 14:02 
Generaloverride Fail() PinsussAnonymous14-Jul-04 15:28 
Generaloverride Fail PinsussAnonymous14-Jul-04 15:27 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140721.1 | Last Updated 23 Dec 2003
Article Copyright 2003 by jconwell
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid