Nunit 4 VsCode .Net 8

[DynConcepts]

Still not working....
See this issue which contained many details.
microsoft/vscode-dotnettools#772

I tried today with a clean machine. Tests discovered and work inVisual Studio 2022, but not in VsCode with NUnit 4

[OsirisTerje]

Just added a repro here.

And it all works, for two different Test Explorers in VSCode, in the Terminal with cmd line, and in the source code.

[DynConcepts]

Thanks... Just pulled local, and it seems to work..... will take a few minutes to see what the difference is...

Ahh... I see it.... you are using the NUnit3TestAdapter... I was deliberately NOT using that as I wanted to avoid picking up or utilizing things written for Nunit 3 and only be using NUnit 4...

[OsirisTerje]

The NUnit3TestAdapter is unfortunately named with that '3' digit inside. We can't change that, without disrupting too much. (Nuget should allow multiple names for the same package though, but not seeing that happen soon).
The adapter version 4.5 runs NUnit 4, and support for .net 8 came in 4.3.2.

[OsirisTerje]

As a cool sidenote, you can run without the adapter, but that will only work on the command line, using the NUnitLite runner. It runs the test project as a command line executable. See https://docs.nunit.org/articles/nunit/running-tests/NUnitLite-Runner.html

[DynConcepts]

Thanks... might not be a bad idea to put that prominently in the documents (on the NuGet feed, in the repo, all over the place) - I spent days trying to figure this out before I reached out and then posted...

Given this information, it seems that if I had a project where some DLL's are linked against NUnit-4 and others against NUnit-3 there is no way to differentiate at the runner level...

The reason this is a concern is I am looking for ways to track "Things that are consuming older things" (NUnit being just one of them). So I guess I will fall back to looking at DLL dependencies and project files (packages, etc.)...

[OsirisTerje]

Yes, I'll go over and look at all the places. I see we write "The NUnit 3 Test Adapter runs NUnit 3.x and higher tests " but I see that can be interpreted as any 3.X versions, whereas it actually means >= 3.

You can see the runner versions in the console output, and the frameworks in the adapter dump logs, if they are enabled. The project files will surely state them of course.

We could add the engine and framework versions to the normal verbosity console logger, since the adapter do have the versions.

Another way is to use the dotnet outdated command, that will show you a list of all outdated packages. See https://www.nuget.org/packages/dotnet-outdated-tool

[manfred-brands]

if I had a project where some DLL's are linked against NUnit-4 and others against NUnit-3 there is no way to differentiate at the runner level...

This would not work. If you don't get compile time errors you will get runtime ones, like MissingMethodException. This is because the signature of methods has changed.

[DynConcepts]

This would not work. If you don't get compile time errors you will get runtime ones, like MissingMethodException.

Consider

a) create one project that references NUnit V3.... everything is good....compiles, 3executes tests..

b) create a totally different project that references NUnit 4V... everything is good....compiles, 3executes tests..

"a" and "b" are completely independent each with their own bin folders, packages, et. al...

Now create a .sln file that includes "a.csproj" and "b.csproj"....

[OsirisTerje]

All would compile fine, and run fine with the NUnit3TestAdapter. In that scenario, dotnet outdated would flag the nunit package in project 'a' as being outdated.

If you however, start with NUnit 4 and create some extension code or something that uses some of the new or changed methods, and then move that code to the project with NUnit 3 you will get compile errors as @manfred-brands mentions.

[manfred-brands]

Thanks @OsirisTerje

If you only use the library functionality and not its tests, there is no issue, although I recommend to separate the tests into a separate project.

If the NUnit 3 project contains NUnit extension methods you call from the NUnit 4 project those will not work as at runtime they look for methods with a NUnit 3 signature in the NUnit 4 dll. Only one of them can be in your output folder.