Eliminate forced stop from the API

[CharliePoole]

The latest versions of .NET Core don't allow us to support forced stop and the methods to invoke it are being completely removed from the framework. Only cooperative stop will be supported in the future.

This affects V3 and V4 of the console runner and engine differently.

Version 4

We'll remove Stop(bool force) entirely from the API. This is a breaking change but much of what it breaks was already non-functional.

The Stop() method without any argument will remain and will invoke a cooperative stop. This implies that tests targeting .NET Core will need to support the cancellation token in order for a stop to work at all.

The forced stop will be replaced in V4 by a Kill() method, which will actually kill the process.

Version 3

The question of whether we need to do something in the version3 code is an open one. Options seem to be

• Do nothing... some version 3 users may need to wait for version 4.
• Make the same change in version 3, which may require some users to upgrade to the latest framework version.
• Attempt to deal with both situations in V3 by adding separate method overloads, with and without the force parameter.

---

@nunit/engine-team @nunit/framework-team Your thoughts?

[OsirisTerje]

V3: My vote: Do nothing :-)

[CharliePoole]

@OsirisTerje That one always wins when it will do the job. :-)

[stevenaw]

I'm in favor of that as well for v3. It sounds easier and less friction for users if it avoids the potential to have to upgrade their framework version. I think we already expect users will have to that framework bump anyways when they do upgrade to v4.

[manfred-brands]

V3: That depends.

There is no fixed relation between the engine and the framework.
So if people can use a V3 engine with both an NUnit < 4.X and NUnit 5.X how will that work?
This first might or might not stop the run, the latter would throw an exception due to mismatched parameters.

Should you update the IsSupportedTestFramework method to return false for NUnit 5.X?
Alternatively you need to keep the version number and when calling StopRun don't pass the force parameter in the latter case.

[CharliePoole]

@manfred-brands That's probably true.

The engine and framework are de-coupled in the sense that neither references the other but, of course, a given version may not have a driver that supports e.g. NUnit 6 or 25 when it comes out. :-)

So the current code is pretty bold in saying it supports NUnit framework with Version.Major >= 3! I'd favor changing that and doing a patch-level release. So far the breaking changes in the V4 framework have been relatively minor and the current driver2 work for all versions through 4.6.1. In fact, I recently updated the engine tests to use that version.

Shall we change it then to say it supports Major versions 3 an 4 but to fail with no driver found for 5+?

[manfred-brands]

Shall we change it then to say it supports Major versions 3 an 4 but to fail with no driver found for 5+?

Yes, that is what I had in mind.