Since the recent releases (so in the last week or so) I've noticed NCrunch becoming unstable when it comes to running tests through a debugger. I'm using the latest version (3.6.0.2) on two different computers and the problems are on both.
I'm using .NET 4.6.1.
Instead of starting the debugger, NCrunch reports errors like:
[18:41:28.5651-EventReader-71] Publishing Event: [DebuggerDetachRequestedEvent:20744]
[18:41:28.5661-EventReader-71] Event [DebuggerDetachRequestedEvent:20744] is being published on thread UIThread to subscriber: .
[18:41:28.5661-EventReader-71] Event [DebuggerDetachRequestedEvent:20744] is being published on thread CoreThread to subscriber: SharedEventPump.
[18:41:28.5661-Core-367] Event [DebuggerDetachRequestedEvent:20744] is being processed on Core thread with subscriber: SharedEventPump.
ENGINE - Process 20744: 18:41:28.5551 [6] - Running 1 tests using executor: nCrunch.Module.NUnit3.Integration.NUnit3FrameworkRuntimeEnvironment
ENGINE - Process 20744: 18:41:28.5621 [10] - System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.
ENGINE - Process 20744: at nCrunch.TestRuntime.Win32.CloseHandle(IntPtr handle)
[18:41:28.5661-EventReader-71] Publishing Event: [ErrorEvent:[Error:
Context: (global)
Category: Internal
Message: System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.
at nCrunch.TestRuntime.Win32.CloseHandle(IntPtr handle)
at nCrunch.TestRuntime.SharedMemoryExecutionDataRecorder.Dispose()
at nCrunch.TestExecution.TestRunnerThread.()
at nCrunch.TestExecution.TestRunnerThread.()
Details:
]]
ENGINE - Process 20744: at nCrunch.TestRuntime.SharedMemoryExecutionDataRecorder.Dispose()
ENGINE - Process 20744: at nCrunch.TestExecution.TestRunnerThread.()
[18:41:28.5661-EventReader-71] Event [ErrorEvent:[Error:
Context: (global)
Category: Internal
Message: System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.
at nCrunch.TestRuntime.Win32.CloseHandle(IntPtr handle)
at nCrunch.TestRuntime.SharedMemoryExecutionDataRecorder.Dispose()
at nCrunch.TestExecution.TestRunnerThread.()
at nCrunch.TestExecution.TestRunnerThread.()
Details:
]] is being published on thread CoreThread to subscriber: ErrorHandler.
Although it doesn't appear the same way for me, I've seen some similar issues around this component lately. I have some ideas on things I can try.
I'll try to get a speculative fix included for this in the next release.
Do you have any estimates on when the next version will be released? Right now using NCrunch is a pain (and the problem with file changes not being detected is still occurring).
offset123 wrote:
Do you have any estimates on when the next version will be released? Right now using NCrunch is a pain (and the problem with file changes not being detected is still occurring).
Sorry, I can't make any promises on this right now. Things have honestly gone completely crazy with the VS2017/.NETCore release. I'll try to get this out when things have settled down a bit.
Remco wrote:
Sorry, I can't make any promises on this right now. Things have honestly gone completely crazy with the VS2017/.NETCore release. I'll try to get this out when things have settled down a bit.
Is it possible to downgrade NCrunch from v3.6 to v3.3 without losing the existing configurations? I don't really need VS2017 and Core stuff.
offset123 wrote:
Is it possible to downgrade NCrunch from v3.6 to v3.3 without losing the existing configurations? I don't really need VS2017 and Core stuff.
Yes, I believe so. I haven't personally tested this, but in theory v3.3 should be forwards compatible with v3.6 configuration files.
offset123 wrote:
Is it possible to downgrade NCrunch from v3.6 to v3.3 without losing the existing configurations? I don't really need VS2017 and Core stuff.
Yes, I believe so. I haven't personally tested this, but in theory v3.3 should be forwards compatible with v3.6 configuration files.
I've uninstalled 3.6 and installed 3.3, the configuration seems to be OK and tests are running, so far so good.
In future, I suggest marking such high-risk releases with lot of new code and support for .NET Core in VS 2017 (which are in themselves unstable, to be fair) as "beta" and keeping the last stable one as a recommended download.