Repository navigation
MissingMethodException when running tests on Mono after bumping to .NET SDK 9.0.300 #116518
Description
Description
After bumping from .NET SDK 9.0.204 to 9.0.300, when an assembly containing code to be tested targets a different version of the .NET Framework than the one being used by the test runner, and the tests are run on Mono (e.g. on macOS or Linux), tests fail with an error like:
System.MissingMethodException : Method not found: Sentry.HttpStatusCodeRange Sentry.HttpStatusCodeRange.op_Implicit(System.ValueTuple`2<int, int>)
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0006a] in <d636f104d58046fd9b195699bcb1a744>:0
When running the same tests using .NET SDK 9.0.204, the same problem does not occur.
Reproduction Steps
See minimal repro at:
Basically clone and run dotnet test from the root folder of that repository on a machine running macOS or Linux (with Mono installed, obviously - I've got 6.14.1 installed on my machine, via homebrew... we see the same behaviour on macOS github runners).
Expected behavior
Expect the tests to pass.
Actual behavior
The tests fail with the error:
MonoReproTests.HttpStatusCodeRangeTests.HttpStatusCodeRange_Excludes_AboveEnd (4ms): Error Message: System.MissingMethodException : Method not found: MonoRepro.HttpStatusCodeRange MonoRepro.HttpStatusCodeRange.op_Implicit(System.ValueTuple`2<int
, int>)
Stack Trace:
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0006a] in <42d7e5fae301407c8
838152bf797a00b>:0
Regression?
This was not a problem in .NET SDK 9.0.204 and earlier. You can see an example of a much more complex solution that has different versions of the .NET Framework in the SDK and test projects in the sentry-dotnet repository (where this issue was first discovered). Version 5.10.0 of the Sentry SDK is targeting net462, while the tests for the same version are targeting net48 (just as in this minimal repro).
Known Workarounds
No response
Configuration
- .NET 9.0.5
- macOS 15.5 (24F74)
- Silicon M2 (Arm64)
Other information
No response
Activity
huoyaoyuan commentedon Jun 12, 2025
Legacy mono and dotnet sdk are not maintained in this repo. The suggestion is to inspect the binaries produced from different SDKs to find the difference.
jamescrosswell commentedon Jun 12, 2025
Thanks for following up @huoyaoyuan. I wasn't sure which repo the issue should go in since I'm using Mono 6.14.1. When creating a new issue in the mono repo it suggests that repo is only for Mono 6.12.0 and prior (later versions are maintained here).
It also seemed relevant that the issue is caused by a bump from .NET 9.0.204 to .NET 9.0.300.
Given both of those things, do you still think the issue should be raised in the mono repo rather than here?
huoyaoyuan commentedon Jun 12, 2025
The later version of legacy mono (6.14) is maintained at https://gitlab.winehq.org/mono/mono .
Not quite. The first step should be get detailed information about what changed in the output. Since
ValueTupleis provided by NuGet package in net46, but inbox in net48, I suspect something about its type identity got messed up.jeffschwMSFT commentedon Jun 16, 2025
closing this issue, indeed mono/mono is the right place for this work. please consider this announcement on the upstream for mono/mono
mono/mono#21796
huoyaoyuan commentedon Jun 17, 2025
If you find something compiled differently, you can also open issue to dotnet/sdk or dotnet/roslyn if you are confirming their problem.