Refactor host rid tests.

[tmds]

Extend host-probes-rid-assets and add a variant that uses the legacy graph for probing with .NET 8+.

Remove the runtime-fallback-graph test in favor of these tests.

[omajid]

Looks like the test runner doesn't patch TargetFramework in nested test directories.

[tmds]

Looks like the test runner doesn't patch TargetFramework in nested test directories.

I'll look into changing the test runner for this.

[tmds]

I'll look into changing the test runner for this.

Rather than extending the patching of csproj files, I've made a PR that makes available the target framework from the test runner as an envvar: https://github.com/redhat-developer/dotnet-bunny/pull/84. It can then be used in the project files as:

<TargetFramework>$(TestTargetFramework)</TargetFramework>

A default value for the property is set in Directory.Build.props.

[omajid]

Hm, any reason why we can't go further and just set an TargetFramework env var directly?

[tmds]

Hm, any reason why we can't go further and just set an TargetFramework env var directly?

To avoid setting a property that is understood by the SDK which can cause it to behave different.

[omajid]

CI says portable RIDs are being computed incorrectly:

 ++ ../../runtime-id --portable
+ runtime_id=fedora.37-x64

[omajid]

Hm, any reason why we can't go further and just set an TargetFramework env var directly?

To avoid setting a property that is understood by the SDK which can cause it to behave different.

Okay. I ask because we override TargetFramework directly in existing .csproj files. I would have thought that has a similar set of concerns.

I am also a bit hesitant about two different approaches to setting TargetFramework in .csproj files - overriding some and relying on environment variables for others.

Anyway, if you like this approach we can go ahead with it.

[tmds]

CI says portable RIDs are being computed incorrectly:

oops... fixed it.

Okay. I ask because we override TargetFramework directly in existing .csproj files. I would have thought that has a similar set of concerns.

The difference is that we're replacing the value only when the project already has a TargetFramework.

If we'd set an envvar, it would be implied for all projects.

I am also a bit hesitant about two different approaches to setting TargetFramework in .csproj files - overriding some and relying on environment variables for others.

I think we should consider applying this to all tests.

[tmds]

Close and re-open to trigger a CI run with the updated testrunner.

[tmds]

The test is failing on Alpine 6.0 and 7.0:

host-probes-rid-assets                                      [FAIL]  (11s)

The log shows it fails to load unix assets:

+ dotnet run --project app
Unhandled exception. System.DllNotFoundException: Unable to load shared library 'mylib-unix' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library libmylib-unix: No such file or directory
   at System.Runtime.InteropServices.NativeLibrary.LoadByName(String libraryName, QCallAssembly callingAssembly, Boolean hasDllImportSearchPathFlag, UInt32 dllImportSearchPathFlag, Boolean throwOnError)
   at System.Runtime.InteropServices.NativeLibrary.LoadLibraryByName(String libraryName, Assembly assembly, Nullable`1 searchPath, Boolean throwOnError)
   at System.Runtime.InteropServices.NativeLibrary.Load(String libraryName, Assembly assembly, Nullable`1 searchPath)
   at Program.<Main>$(String[] args) in /__w/dotnet-regular-tests/dotnet-regular-tests/host-probes-rid-assets/app/Program.cs:line 4
Process Exit Code: 134

It may have to do with the VERSION_ID on alpine:edge:

# cat /etc/os-release 
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.19_alpha20230901
PRETTY_NAME="Alpine Linux edge"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"

On the alpine:latest image the test passes.

I'm going to configure the test to skip on Alpine.

cc @ayakael