I have a set of NUnit tests (running using the Resharper test runner), and some of those fail due to assertion exceptions happening in background threads; and when this happens VS2017 breaks into the debugger, what is undesirable as I want it to keep on running other tests.
- All the settings in "Exception Settings/CLR/Thrown" are turned off.
- The "User-Unhandled" settings in that dialog aren't present whether I switch the "Just My Code" option on or off
- All the "Exception Settings/Managed Debugging Assistants" settings are turned off.
Any other ideas how to prevent it from breaking on those exceptions?
The first thing I'll mention is that assertion exceptions shouldn't be propagating out of your testing framework. If they are, then it could be because of some sneaky code that I can't conceive of. In other words, all assertion exceptions are inherently "handled", because your test framework will handle them for you.
There is also a concept of running vs. debugging a test. If your intention is to simply ignore all exceptions everywhere in your tests, then you should just choose to run - and VS will not attach the debugger at all (and then can't break). I don't know what this difference looks like in resharper's test runner, but in VS it's under the Test > Run and Test > Debug menu respectively.
If you can't re-architect your tests, and you want to be debugging other exceptions (just not assertion exceptions) or you want to hit break points, read the following:
By default, the new debugger (2015+) will break when an exception is un-handled - but you can turn this behaviour off for all exceptions or just a specific one.
- Open the exception settings window (Debug
> Windows > Exception Settings)
- Right click on "Common Language Runtime Exceptions" (or the specific exception you want to change)
- In the right click menu click "Continue When Unhandled in User Code".
You should now see a the text "Continue when unhandled in user code" on the right hand side of the window under the "Additional Actions" column and VS should no longer break.
Apparently, this was a bug in Visual Studio. Installing the later updates has fixed it.
