Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

NCrunch testrunner crashes on a Debugger.Break()
abelb
#1 Posted : Tuesday, September 19, 2017 5:19:41 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/12/2014(UTC)
Posts: 121
Location: Netherlands

Thanks: 11 times
Was thanked: 10 time(s) in 10 post(s)
I'm not sure this is "by design", but the behavior surprised me. When you have a Debugger.Break() somewhere in your test code (not common, I know), then the NCrunch testrunner process will crash. It does, however, run the whole test if you dismiss the crash dialog box popup, which is rather odd.

Code:
[Test]
public void ShouldNotCrashOnBreak()
{
    Console.WriteLine("Before break");
    Debugger.Break();
    Console.WriteLine("After break");
    Assert.AreEqual(true, true);
}


The crash window:

Remco
#2 Posted : Tuesday, September 19, 2017 11:51:59 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 4,864

Thanks: 648 times
Was thanked: 752 time(s) in 717 post(s)
This is handled by the O/S itself. I guess it's possible for NCrunch to rip these calls out during instrumentation, but sometimes they can be useful if you want to hook a debugger onto a running session (which I believe is often the intention).

I think it would be rather messy or even detrimental for NCrunch to try and avoid showing this dialog.
abelb
#3 Posted : Wednesday, September 20, 2017 12:44:25 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/12/2014(UTC)
Posts: 121
Location: Netherlands

Thanks: 11 times
Was thanked: 10 time(s) in 10 post(s)
Avoiding it is probably a bad idea, after all the Break() instruction is encountered. And thinking about it now it makes sense. However, a better dialog text would be welcome, but I guess I should consult Microsoft on that. Unless you want to hook Break() (which is not that hard, you don't need to remove it with instrumention, just attach a dummy debugger, which will then automatically be called, which then shows an NCrunch-style dialog). But I can imagine you have bigger fish to fry ;)

EDIT: a good workaround (in case a break is needed) would be to use Debugger.Launch(), which launches the dialog box with available debuggers, which is much clearer.
1 user thanked abelb for this useful post.
Remco on 9/20/2017(UTC)
Users browsing this topic
Guest (3)
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.020 seconds.