Rename the console runner for version 4

[CharliePoole]

Clearly, nunit3-console.exe no longer works. Could be nunit4-console.exe of course. Or something entirely different?

@nunit/engine-team What do you think?

[jnm2]

Having the number in there struck me as odd, but if the containing folders are in %path% (or invoked as .NET global tools) then this would allow you to have multiple at once and choose which one you want. I'm not sure if this is a likely situation.

What about nunit.exe? Most console apps don't have console in the file name.

[CharliePoole]

Nunit.exe was once the name of our gui, but of course, that's no longer relevant.

These days, I can see two possible drawbacks, but I'm not sure if they are really a problem...

1. We currently use dotnet nunit to run our CLI tool. If we keep the same design, where the net6.0 build of the console runner becomes the tool itself, then no problem. But if we have a separate tool, even just a wrapper, it might be a conflict.

2. I've toyed with the idea of a general nunit command, with subcommands. It may be worthwhile to keep that door open.

"Most console apps don't have console in the file name."

Good point! maybe we should look at what others call their batch runners.

One thought... we could use nunit4-console while we are developing to avoid confusion with version 3 and plan on a final selection before the actual release.

[OsirisTerje]

The name is also equal to the nuget id. Changing it would mean that the chain would be broken there. It might not be a problem for the console itself though, since it is a separate tool. The adapter and the engine which are included in projects though, it would be much harder to change. Calling it nunit.exe could be interesting, but it would also mark it as THE Nunit tool. Perhaps it is?

[CharliePoole]

@OsirisTerje

Actually, the nuget id for nuget.org is NUnit.ConsoleRunner while the one used for chocolatey.org is nunit-console-runner. The name of the exe included in the packages makes a breaking change, of course, but this is a major update so it's permitted.

Good point about the tool. Our two notes may have crossed. Currently the net 6.0 build of the console runner is the dotnet tool. However, it lacks some features a tool needs and we plan to add features a tool doesn't usually have. So I'm thinking that the tool (except for it's name) is up in the air.

All stated, maybe we have to leave it up in the air for a while. :-)

Charlie

BTW, Terje, I hope you are following the discussion of breaking changes in the engine!

[OsirisTerje]

I have been drowning in NUnit notifications, see there are a bunch I have missed. Thanks for the heads up on the breaking changes, I'll get to that discussion.

Another thing, I tried to install the dotnet core tool, but that fails. (Ref https://www.nuget.org/packages/NUnit.ConsoleRunner.NetCore/) But this might be the outdated one?? Also, the NUnit.Consolerunner is a package, not a tool (which doesn't make sense to me) . What am I missing here?

[CharliePoole]

NUnit.ConsoleRunner previously built two console runner targets: net20 and netcoreapp3.1. Using a lot of conditional code, the two builds really end up producing what amounts to two different applications. The netcoreapp3.1 is actually built as a tool. So you have two executables named nunit3-console.exe and nunit3-console.dll, the first being our standard runner and the second being our tool. I don't like this and I'm planning to change it.

In the latest 4.0 dev builds, the only change is to substitute net6.0 for netcoreapp3.1. We still have the same anti-pattern of two applications from one project. I'm focused on other things right now, but I'd like to gather info about exactly what we want a tool to be able to do. Then our net6.0 build of nunit-console can grow to become a full-fledged runner, starting processes, handling extensions, etc. while our dotnet tool can be a different project, possibly with independent code, possibly just wrapping the nunit-console net6.0 build and making use of it in a controlled way.

Everything you see in 3.15, of course, is limited to non-breaking changes I could make.

You're welcome to join in the engine team discussions about where this is going and/or we can set up a phone call some time!

[CharliePoole]

Based on comments... I'm thinking we should treat nunit3-console as an anomaly and just go back to nunit-console (as it was before v3) or to some other name without a version in it.

For now, I think we should avoid using nunit but if it turns out there's no problem using it for two things, we could change again before the final release. So... other ideas for a console/batch runner name for nunit tests?

[siprbaum]

@CharliePoole Doesn't this name change conflict with nunit2, where the runner was also named nunit-console.exe?
I just looked into https://github.com/nunit-legacy/nunitv2/releases/download/2.7.1/NUnit-2.7.1.zip and saw that it indeed uses
nunit-console.exe for its console runner.

[CharliePoole]

Yes, that's what I meant by "go back to nunit-console", treating our use of nunit3-console as an anomaly.

Do you have a specific use case which presents a conflict for you?