Create a .NET 8.0 build of the engine

[CharliePoole]

This is needed so we and others can write clients under .NET 8.0. Currently, a .NET 8.0 client uses the netstandard 2.0 build of the engine, which lacks all the features needed to resolve dependencies. This lack seems to be the source of a number of bugs which I hope we will be able to resolve as a result.

An experimental build of the engine is currently avaliable in our MyGet feed, version 3.18.3-dev00006 and later.

[CharliePoole]

Question for discussion: I'm currently building an the engine for .NET 6.0 as well in an experimental build. It's another build with no differences from the .NET 8.0 build so I would propose to maintain it and have the .NET 6.0 NetCore runner use it for as long as we maintain that runner. The .Net 6.0 runner currently uses the NetStandard2.0 engine, which is not very satisfactory.

[mikkelbu]

I've not had time to follow the discussions - or work - in this repository for some time (trying to catch up on it this weekend), but I don't see a problem with both having a .NET6 and .NET8 build of the engine as long as the day-to-day overhead is not too large.

[CharliePoole]

If we have two, we might have three some day. Or we might have two but change what they are - e.g. 8.0 and 9.0. In that case, it would be simpler to not keep changing the name of the standard one to NUnit and just call them, NUnit-NetXX.

I'm not familiar with the internals of tools but it's open source so figure-out-able. I'm guessing I could put a bit of unmanaged code in exe to consume an option or something and decide which internal code to use. But it's one of those problems that's interesting enough so you feel like trying even if it's not useful and I'd like to know more about what people need before diving into it.

@mikkelbu Maybe you'd like to catch up by trying one of the issues? :-)

[OsirisTerje]

Just to be clear:
The problem is a NUnit.Console issue, not a NUnit.Engine issue, right ? Because the Engine is a library, so that will use whatever matches the calling assembly, in this case the Console. And the engine package can contain multiple different framework versions, e.g. two or three.
About the Console, it can run with the highest available SDK version, or whatever that has been set to, correct?

[CharliePoole]

@OsirisTerje
Exactly. More generally, it's a problem with executable apps in general, since what is run is precisely the app you specify, whereas library packages are loaded by .NET. So it's only a problem with the console because we decided that the .NET Core runner should be a dotnet tool. If it were a console dll that we ran using dotnet run or dotnet exec things might be different. But we (and users) wanted a tool and that seems to be the right choice.

In particular, it has nothing to do with the engine as used by the adapter.

Regarding running the console... assuming we mean the .NET 6.0 or 8.0 build ... both of them can run using a higher SDK if one for which they are built is not available or if the user plays with some settings. As you pointed out, .NET 9.0 introduces a command-line option to do that.

You could probably manipulate settings to trick the 8.0 build to run under 6.0, but I'm not sure it will work. Or it might work until it hits a test that sends it down a particular branch of code that throws an exception. That's one of the things I want to experiment with in an isolated VM.

Obviously, we could (in future) create a dotnet equivalent of the standard runner, with agents launched to run tests under the correct runtime.

[OsirisTerje]

I have been testing it with a small tool I made, https://www.nuget.org/packages/MultiFrameworkTool, for this purpose.

It has two targets internally, net 6 and net 8. It displays what code it is running, and it displays what running sdk it runs under.

If I run this on my work machine, which has net 9 rc, net 8 and net 6 installed, it always comes out with both as .net 8.
It completely ignores global.json settings. That is something I really dont understand why. It should adhere to that.

If I run it on another older machine I have, which has .net 7 and .net 5 installed (don't ask) - it comes out as .net 6 code and .net 6 running. It may be that my runningsdk detection is off, but... the code itself doesnt lie.

The source is here: https://github.com/OsirisTerje/MultiFramworkTool

[manfred-brands]

@OsirisTerje I have compiled your tool.

If I install it as a local tool it seems to obey global.json for me. But that could be just the dotnet tool run command.

If I installing it globally, it always says .NET8.0.

Digging further, it seems to depend on the SDK used to install the tool:

[CharliePoole]

Adding to my recent comment,,,

If we were to decide (now or v4) to drop the netcore runner aka dotnet tool, the console runner and engine could be simplified quite a bit. There are things in there now like distinguishing valid options between the different builds that would no longer be needed.

On the other hand, I'd favor continuing to build the engine and maybe even the runner for .NET 8.0 because I'm pretty sure you will eventually want to stop using the .NET Framework as the host process for the runner.

[CharliePoole]

As a result of discussions under #1493, we will have a .NET 8.0 console runner in future rather than (not in addition to) a .NET 6.0 runner. The .NET 8.0 runner uses the .NET 8.0 engine so the .NET 6.0 engine is no longer needed.

Therefore, for 3.19, I'll retain the .NET 8.0 engine build and drop the .NET 6.0 build.

The .NET 8.0 runner may have features added to it for future use, either in 3.19 or a later release. That is, features now suppressed via conditional compilation will be "unsuppresed" and tested. However, to avoid unplanned breaking changes to the console runner, any such features will be hidden from the .NET 8.0 runner, most likely using a feature switch.

The motivation for doing this is the expectation that we will eventually want a version of the standard console runner that works in an environment without the .NET Framework installed.

[CharliePoole]

This issue has been resolved in version 3.19.0

The release is available on:
GitHub.
NuGet packages are also available NuGet.org and
Chocolatey Packages may be found at Chocolatey.org