runtime: [mono?] Cannot run host tests due to xunit version mismatch
Description
Attempting to run the host tests on a Mono-based linux-s390x runtime fails with:
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load type of field 'Xunit.ConsoleClient.ConsoleRunner:completionMessages' (3) due to: Could not load file or assembly 'xunit.runner.utility.netcoreapp10, Version=2.4.2.0, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c' or one of its dependencies.
Reproduction Steps
Run ./build host.tests --test on the current release/6.0 branch on linux-s390x.
Expected behavior
Test execution starts.
Actual behavior
Test fails to start with the error message shown above.
Regression?
Yes. This worked before https://github.com/dotnet/runtime/commit/491ed9a112559872c31ae40da8f6d9977ba4ce3a .
Known Workarounds
Revert XUnitVersion back to 2.4.1. (This also requires moving to back-level versions of MicrosoftDotNetXUnitExtensionsVersion and MicrosoftDotNetXUnitConsoleRunnerVersion.)
Configuration
Runtime from current .NET 6 branch built on linux-s390x.
Other information
The root cause of the issue appears to be that the host tests (e.g. Microsoft.NET.HostModel.AppHost.Tests) depend on both
"xunit.runner.console": "2.4.2-pre.9",
and
"xunit.runner.visualstudio": "2.4.2"
Both of these packages bring their own copy of xunit.runner.utility.netcoreapp10.dll, but in two different versions. xunit.runner.console version 2.4.2-pre.9 brings version 2.4.2 of that DLL, while xunit.runner.visualstudio version 2.4.2 brings version 2.4.1 of that DLL.
During restore, it looks like one of those copies “wins”, and this happens to be the older one (2.4.1). This causes the Mono loader error while loading dependencies of xunit.runner.console, which expects the newer version (2.4.2).
I tried to re-create the issue on Intel, but there I’m not seeing the error, even though the overall situation looks identical. So maybe part of the root cause may also involve the Mono loader - maybe this is more strict in checking version matches than the CoreCLR loader for some reason?
About this issue
- Original URL
- State: open
- Created 3 years ago
- Comments: 26 (26 by maintainers)
Commits related to this issue
- [metadata] Add "special jit flags" to MonoClass Add a rarely used MonoClass property for "special jit flags" (`m_class_has_special_jit_flags` and `mono_class_get_special_jit_flags`) that is set at cl... — committed to lambdageek/runtime by lambdageek 3 years ago
- [mini] Add a jit icall for newobj construction Avoid calling `mono_class_init_internal` for classes marked with `MONO_SPECIAL_JIT_USE_ICALL_NEWOBJ` until runtime, rather than JIT-time. Related to ht... — committed to lambdageek/runtime by lambdageek 3 years ago
- [metadata] Add "special jit flags" to MonoClass Add a rarely used MonoClass property for "special jit flags" (`m_class_has_special_jit_flags` and `mono_class_get_special_jit_flags`) that is set at cl... — committed to lambdageek/runtime by lambdageek 3 years ago
- [mini] Add a jit icall for newobj construction Avoid calling `mono_class_init_internal` for classes marked with `MONO_SPECIAL_JIT_USE_ICALL_NEWOBJ` until runtime, rather than JIT-time. Related to ht... — committed to lambdageek/runtime by lambdageek 3 years ago
- [xunit.console] Move ConsoleRunner creation to a separate function On platforms where Mono is the dotnet SDK runtime (Linux s390x, currently), work around a limitation of the Mono JIT by moving the i... — committed to lambdageek/xunit by lambdageek 3 years ago
- [metadata] Add "special jit flags" to MonoClass Add a rarely used MonoClass property for "special jit flags" (`m_class_has_special_jit_flags` and `mono_class_get_special_jit_flags`) that is set at cl... — committed to lambdageek/runtime by lambdageek 3 years ago
- [mini] Add a jit icall for newobj construction Avoid calling `mono_class_init_internal` for classes marked with `MONO_SPECIAL_JIT_USE_ICALL_NEWOBJ` until runtime, rather than JIT-time. Related to ht... — committed to lambdageek/runtime by lambdageek 3 years ago
- [metadata] Add "special jit flags" to MonoClass Add a rarely used MonoClass property for "special jit flags" (`m_class_has_special_jit_flags` and `mono_class_get_special_jit_flags`) that is set at cl... — committed to lambdageek/runtime by lambdageek 3 years ago
- [mini] Add a jit icall for newobj construction Avoid calling `mono_class_init_internal` for classes marked with `MONO_SPECIAL_JIT_USE_ICALL_NEWOBJ` until runtime, rather than JIT-time. Related to ht... — committed to lambdageek/runtime by lambdageek 3 years ago
- [metadata] Add "special jit flags" to MonoClass Add a rarely used MonoClass property for "special jit flags" (`m_class_has_special_jit_flags` and `mono_class_get_special_jit_flags`) that is set at cl... — committed to lambdageek/runtime by lambdageek 3 years ago
- [mini] Add a jit icall for newobj construction Avoid calling `mono_class_init_internal` for classes marked with `MONO_SPECIAL_JIT_USE_ICALL_NEWOBJ` until runtime, rather than JIT-time. Related to ht... — committed to lambdageek/runtime by lambdageek 3 years ago
- [metadata] Add "special jit flags" to MonoClass Add a rarely used MonoClass property for "special jit flags" (`m_class_has_special_jit_flags` and `mono_class_get_special_jit_flags`) that is set at cl... — committed to lambdageek/runtime by lambdageek 3 years ago
- [mini] Add a jit icall for newobj construction Avoid calling `mono_class_init_internal` for classes marked with `MONO_SPECIAL_JIT_USE_ICALL_NEWOBJ` until runtime, rather than JIT-time. Related to ht... — committed to lambdageek/runtime by lambdageek 3 years ago
I don’t think the installer tests do anything special, they just use the “normal” arcade logic for test projects, which always uses the upstream console runner.
For the library tests, in contrast, we have
src/libraries/Directory.Build.propsdo:and that file
eng/testing/tests.propshas logic that appears to be responsible for overriding arcade and doing something special. This file is not used by the installer tests.