Crash when executing x86 .NET 7.0 assembly on 3.16.3

[stephan-hanselmann]

When I run a .NET 7.0 assembly built for x86 platform, the console (3.16.3) fails with the following error.

When I try the same project built for Any CPU, the assembly runs completely fine.

NUnit console 3.16.0 also works fine with assembly built for x86.

[CharliePoole]

As far as I can figure out, all .NET Core X86 tests stopped working in 16.3. There are a number of issues that reference X86, which may be resolved if we can get it working again.

One problem is that we have been suppressing execution of X86 tests in AppVeyor for some time, rather than testing if dotnet X86 is available. I recently fixed that in main, only do discover that it fails if we try to run it.

Another problem is that we only have package tests for X86 under .NET Core 3.1. We should add them for 6.0 and 8.0 as well.

I'm making this the primary issue for the overall X86 execution problem. Others will be resolved depending on whether closing this issue fixes them as well.

This issue applies to both main and the version3X branches.

[CharliePoole]

Status

• Verified failure in both the standard nunit3-console.exe and the dotnet NUnit tool.
• Using main branch, verified correct agent is used and that correct args are passed.
• Added tests under .NET 6.0 and 8.0, which also fail in both runners
• Now running locally, but failing under AppVeyor due to the use of a fixed path for X86
• Using the windows registry to get the path still fails in AppVeyor. See separate comment below.

[CharliePoole]

Fixed this for the standard console runner. However, the dotnet console tool will require a different approach. I'll create a separate issue with more detail of the problem.

[CharliePoole]

I believe I've found the root cause and it's fairly deep in the engine.

Our representation of target runtimes is the RuntimeFramework class, which was developed long before dotnet core existed and extended to accomodate it. For several reasons it's a poor fit and I've had it on my agenda to replace it for a while.

What I hadn't thought about is this key problem... In .NET Framework, a particular runtime supports both X64 and X86 architectures. In .NET Core, you may have only X64 installed or only X86 or a mix. If you have both, you may have different versions. It depends on how you do your installations.

On my local machine, I happen to have all the same versions of .NET installed for both 64- and 32-bits. The fix I have works for me and, I suspect, will work for anyone who has installed a set of runtimes using defaults. Running some tests on Appveyor to display their directory, I could see that only .NET 8.0 is available for X86, which may explain the failures there. The fix I have won't help anyone with a similar installation pattern, but it still may be worth merging.

In the short term, we need to have a separate list of available runtimes for X64 and X86 in the engine. In the longer term, we need a new representation for target frameworks, probably based on FrameworkName and using standard TFMs rather than our existing NUnit ids. The longer term change will be breaking, so is limited to v4.

I've been working on V4 but I think that it's probably more important right now to get V3 working wrt this issue. In fact, we may decide to leave V4's X86 support broken until it can be replaced entirely.

@OsirisTerje Aside from yourself, are there team members who need to be aware of this issue?

[CharliePoole]

For anyone who's interested in the intimate details of the AppVeyor problem, here is the output of a Cake task I wrote to display what's installed in their VS 2022 agent...

========================================
DotnetInfo
========================================
Install Path:      C:\Program Files\dotnet\
Executable:        C:\Program Files\dotnet\dotnet.exe
Runtimes:
  Microsoft.AspNetCore.App 3.1.32
  Microsoft.AspNetCore.App 3.1.4
  Microsoft.AspNetCore.App 5.0.17
  Microsoft.AspNetCore.App 6.0.23
  Microsoft.AspNetCore.App 7.0.12
  Microsoft.AspNetCore.App 8.0.3
  Microsoft.NETCore.App 3.1.32
  Microsoft.NETCore.App 3.1.4
  Microsoft.NETCore.App 5.0.17
  Microsoft.NETCore.App 6.0.23
  Microsoft.NETCore.App 7.0.12
  Microsoft.NETCore.App 8.0.3
  Microsoft.WindowsDesktop.App 3.1.32
  Microsoft.WindowsDesktop.App 3.1.4
  Microsoft.WindowsDesktop.App 5.0.17
  Microsoft.WindowsDesktop.App 6.0.23
  Microsoft.WindowsDesktop.App 7.0.12
  Microsoft.WindowsDesktop.App 8.0.3
X86 Install Path:  C:\Program Files (x86)\dotnet\
X86 Executable:    C:\Program Files (x86)\dotnet\dotnet.exe
Runtimes:
  Microsoft.AspNetCore.App 8.0.3
  Microsoft.NETCore.App 8.0.3
  Microsoft.WindowsDesktop.App 8.0.3

[OsirisTerje]

Aside from yourself, are there team members who need to be aware of this issue?

Unfortunately, no.

[CharliePoole]

@stephan-hanselmann Automatically closed by merge to mainversion4, but this needs to be fixed in the version3Xmain branch to be useful for you.

[UPDATED to reflect change in names of the branches]

[CharliePoole]

Will be in the next 3.x release. Available now from our myget feed as version 3.17.1-dev00034.