Xunit: Exiting dotnet-xunit does not shutdown xunit.console

[JohnRusk]

This can be a problem in CI builds if, due to some error in test design, the tests run for an unusually long time. The build system may cancel the build due to a timeout, or a user may manually cancel it. But xunit.console continues running. Then, when you try to run the build again, you can't, because xunit.console is locking files in the output directories. This necessitates going onto the build agent machine, and manually stopping the process. This is particularly troublesome if you happen to be a team member who does not have login access to that machine.

To Reproduce

I observed this effect when using VSTS as the build server.

To reproduce it more simply, outside of a build server, do this:

1. In one PowerShell window, in the root folder of a suitable .NET Core test project, run dotnet xunit -framework net461 (Presumably any .NET Framework version will do). You'll need to make sure that your test project takes at least a few 10s of seconds to run, so you can observe the effect. Or, to really demonstrate it convincingly, put an endless loop in one of your tests, to simulate some kind of problem that makes the tests take a long time.
2. WHILE the above is running, run these commands in another PowerShell window:
   2.1. Get-Process dotnet,xunit.console -EA SilentlyContinue (If you run it a few seconds after testing starts, it will show both processes running)
   2.2. Stop-Process -name dotnet
   2.3 Get-Process dotnet,xunit.console -EA SilentlyContinue Will show that xunit.console is still running.

Suggested solution

Make the shutdown of dotnet.exe also result in the shutdown of the xunit.console process which it launched. There are a range of possible ways to implement this here: https://stackoverflow.com/questions/3342941/kill-child-process-when-parent-process-is-killed . Hopefully one of the easy options may be achievable in this case.

[smbecker]

The same occurs if you just hit CTRL+C while a test is running.

[gozineha]

test project takes at least a few 10s of seconds to run, so you can observe the effect. Or, to really demonstrate it convincingly, put an endless loop in one of your tests, to simulate some kind of problem that makes the tests take a long time.

[bradwilson]

The fix I've added for this is to improve Ctrl+C handling. Now, when the user presses Ctrl+C during one of the dotnet build or msbuild steps, we see that cancellation and let it bubble up; when the user presses Ctrl+C during dotnet xunit.console.dll or xunit.console.exe, the existing handlers will be in place (attempting graceful shutdown, but allowing full-on termination with a second press of Ctrl+C). Either way, we see this and stop the process.

I do not intend to add any special logic around non-graceful process termination of dotnet xunit itself, as this is not a user scenario we feel is worth addressing. End users will normally use Ctrl+C to terminate a process that they are using interactively.

This will ship in 2.3.1.