Preprocessor? .NET don’t need no stinkin’ preprocessor! [DebugEx.Assert provides meaningful assertion failure messages automagically!]

This blog has moved to a new location and comments have been disabled.

All old posts, new posts, and comments can be found on The blog of

See you there!

Comments (2)
  1. RichardDeeming says:

    It's a shame this dialog box still has "Abort", "Retry" and "Ignore" buttons. They're obviously not the right captions, since the header has to include an explanation: "Abort=Quit, Retry=Debug, Ignore=Continue".

    At the very least, I would expect the buttons to have the correct captions – "Quit", "Debug" and "Continue". That would probably be good enough for a developer, but it might lead some to copy this UI for the users. A better option would be a task dialog with three command links, including a proper description of each option.

  2. David Anson says:

    Richard Deeming,

    Yeah, the buttons on that dialog have always bugged me, too! 🙂 From the point of view of what I did in this post, that's kind of a side issue because DebugEx.Assert simply calls through to the normal Debug.Assert method. The benefit of this approach is that the resulting experience (UI/debugger/etc.) is the same (with a better message!). The drawback is that the resulting experience is the same – warts and all.

    If I had to guess, I'd say the reason for the poorly-named buttons is probably that the underlying implementation is using a standard Win32 MessageBox which is guaranteed to work everywhere (i.e., regardless of platform, UI framework, etc..). Something like a task dialog depends on a particular version of the OS and might require quite a lot more supporting infrastructure. Because this UI needs to work every time and is never supposed to show up for customers, the current implementation doesn't seem all that unreasonable to me.

Comments are closed.

Skip to main content