I'm debugging a small WPF application with VS2013 Community, .Net 4.5, and a 3rd party graphing library, and sometimes when I F5-Launch, my Debug.Assert failures don't prompt or break in the debugger, they only get written to the debug output... (expected behavior if AssertUiEnabled == false, but... I'm leaving it true).
I'm using the DefaultTraceListener, and I have not defined an <assert> element in my configuration file.
I can't reproduce reliably, but I've witnessed while debugging that sometimes ((DefaultTraceListener)Debug.Listeners[0]).AssertUiEnabled == false, and it seems to happen when I start using QuickWatch and/or F10 stepping through code. My perception is that it's related to switching the active window away from the wpf app that's being debugged. AssertUiEnabled starts true, and then after unknown repro steps that include F10-StepOver and CtrlDQ-QuickWatch I observe it to be false.
QUESTION: Is there any reason for AssertUiEnabled to be setting itself to false when I'm switching between windows or opening/closing the QuickWatch window in VS2013?
I believe what I'm seeing is root cause for Causing VS2010 debugger to break when Debug.Assert fails - (OP asking why he's not getting debugger to break on assert.fail)
I've read some articles about adding custom TraceListeners when debugging web services, and how the DefaultTraceListener in Mono defaults to AssertUiEnabled = false but I think the .Net 4.5 runtime's DefaultTraceListener is what I want, it's just self-disabling the AssertUI for unknown reason. I can work around it but I'm curious why the value is changing.