Debug.Assert (false) löst nicht in win8 Metro apps

Question

Ich bemerke Debug.Assert löst nicht in Metro-Apps, jedoch, wenn das Projekt ein traditionelles wie Console oder WinForm ist, wird es ausgelöst. Und ja, ich bin im Debug-Modus.

Ist eine Einstellung in Visual Studio (11 Beta) nicht richtig eingestellt? Oder Debug.Assert soll in Metro-Apps deaktiviert sein?

Ich weiß, dass viele Ausnahmen während der Ausführung von Metro-Apps verschluckt werden, aber Debug.Assert ist so praktisch, dass ich keinen Grund finden kann, warum es deaktiviert werden sollte.

Answer 1

Es ist Trigger, im Ausgabefenster sehen. Es fragt Sie nicht automatisch, ob Sie eine Debugger-Unterbrechung wünschen und fährt damit einfach weiter.

Die Eigenschaft DefaultTraceListener.AssertUIEnabled ist false. Dies ist ein Implementierungsproblem. Es kann kein Nachrichtenfeld über der Metro-Benutzeroberfläche angezeigt werden. Was funktioniert eigentlich, aber der Monitor schaltet auf den Desktop, ziemlich unerwünscht, wenn Sie gerne Nein geklickt hätten. Schwer zu lösen und ohne Zweifel auf der ToDo-Liste. Sie können nicht einfach auf die Eigenschaft zugreifen, um sie auf "true" zu setzen. Auf die Metadaten kann nicht zugegriffen werden. Filip's Workaround klingt halbwegs anständig.

Answer 2

Scheint wie ein Fehler. Ich würde meine eigene Assert-Methode einführen. Etwas wie:

[Conditional("DEBUG")] 
public static void Assert(bool condition) 
{ 
    if (!condition) 
     System.Diagnostics.Debugger.Break(); 
} 

Answer 3

Es gibt das gleiche Problem mit F # in WinRT, in VS2013. Die -Anweisung, die ein Alias ​​für System.Diagnostics.Debug.Assert ist, löst keine Ausnahme aus. Wenn Sie also das Ausgabefenster nicht beobachten, können Ihre Assertionen fehlschlagen, ohne dass sie bemerkt werden. Selbst wenn Sie zusehen, ist es schwierig, die Stelle zu finden, an der die Behauptung erhoben wurde.

Ich folgte Filip Vorschlag und einen kurzen Gebrauch schrieb wie folge:

namespace MyProj.Infrastructure 

module Diagnostics = 

    let Assert condition = if not condition then 
           System.Diagnostics.Debugger.Break() 

ich Debugger.Break über eine Ausnahme ausgelöst entschieden, weil es den Debugger an der Stelle hält die Behauptung fehlschlägt. Eine Ausnahme ist jedoch eine akzeptable Alternative.

Ich hatte noch keine passenden globalen Projekte oder Module in meiner Lösung, also musste ich sie nur dafür erstellen, was ziemlich nervig war.