Menu
When debugging a unit test through either the TEST menu or the right-click context menu, VS2013 always ignores the breakpoint in the unit test after making a code change to the current c# test class. Debugging a second time causes the breakpoint to be hit.
784
If a source file has changed and the source no longer matches the code you're debugging, the debugger won't set breakpoints in the code by default. Normally, this problem happens when a source file is changed, but the source code wasn't rebuilt. To fix this issue, rebuild the project.
First Close Visual Studio, Open Project again in Visual Studio -> Clean Solution, and then Rebuild Solution. Make sure, you have set the configuration to "Debug" mode and you are not working on "Release" mode while debugging your application. Click "Ok" and re-build your project.
To set a breakpoint in source code: Click in the far left margin next to a line of code. You can also select the line and press F9, select Debug > Toggle Breakpoint, or right-click and select Breakpoint > Insert breakpoint. The breakpoint appears as a red dot in the left margin.
In Debug mode, there are no optimizations, which means debug builds can run slower than Release build.
My suspicion is that this has to do with VS2013's new feature "Keep Test Execution Engine Running".
You can toggle that feature in Visual Studio's menu via "TEST - Test Settings".
You might also be able to specify that behaviour by using a runsettings file with KeepExecutorAliveAfterLegacyRun set to false: http://msdn.microsoft.com/en-us/library/vstudio/jj635153.aspx.
149
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
