[Mono] StackTraceHelper tests fail on Mono due to generic type parameter differences

[medhatiwari]

Summary

6 StackTraceHelper tests fail on Mono because of differences in how generic type parameters are represented in stack traces compared to CoreCLR.

Environment

• Runtime: Mono on x64/ppc64le/s390x (RHEL 10)
• Target Framework: net10.0
• Test Project: Microsoft.AspNetCore.Shared.Tests

Failing Tests

1. StackTraceHelper_PrettyPrintsStackTraceForGenericMethods

Assert.Equal() Failure: Strings differ
                                              ↓ (pos 65)
Expected: ···"ckTraceHelperTest.GenericMethod<T>(T val)"
Actual:   ···"perTest.GenericMethod<string>(string val)"
                                    ↑ (pos 65)

2. StackTraceHelper_PrettyPrintsStackTraceForMethodsWithGenericOutParameters

Assert.Equal() Failure: Strings differ
                                  ↓ (pos 81)
Expected: ···"GenericOutParameter<TVal>(string a, out T"···
Actual:   ···"GenericOutParameter<int>(string a, out in"···
                                  ↑ (pos 81)

3. StackTraceHelper_PrettyPrintsStackTraceForMethodsOnGenericTypes

Assert.Equal() Failure: Strings differ
                                  ↓ (pos 64)
Expected: ···"erTest+GenericClass<T>.Throw(T parameter)"
Actual:   ···"erTest+GenericClass<int>.Throw(int parame"···
                                  ↑ (pos 64)

4. StackTraceHelper_PrettyPrintsStackTraceForMethodsWithGenericRefParameters

Assert.Equal() Failure: Strings differ
                                  ↓ (pos 81)
Expected: ···"GenericRefParameter<TVal>(ref TVal value)"
Actual:   ···"thGenericRefParameter<int>(ref int value)"
                                    ↑ (pos 81)

5. StackTraceHelper_ProducesReadableOutput

Assert.Equal() Failure: Collections differ
                                                                                 ↓ (pos 2)
Expected: List<string> ["Microsoft.Extensions.Internal.StackTraceHelperTest"···, ...]
Actual:   string[]     ["Microsoft.Extensions.Internal.StackTraceHelperTest"···, ...]
                                                                                 ↑ (pos 2)

6. GetFrames_DoesNotFailForDynamicallyGeneratedAssemblies

Assert.StartsWith() Failure: String start does not match
String:         "object.lambda_method34(Closure )"
Expected start: "lambda_method"

Behavior Difference

On CoreCLR (Working)

• Generic methods show: GenericMethod<T>(T val)
• Generic type methods show: GenericClass<T>.Method(T param)
• Lambda methods show: lambda_method34(Closure )

On Mono (Failing)

• Generic methods show: GenericMethod<string>(string val) (concrete types)
• Generic type methods show: GenericClass<int>.Method(int param) (concrete types)
• Lambda methods show: object.lambda_method34(Closure ) (includes declaring type)

Test Results Summary

• CoreCLR: 13 total, 13 passed, 0 failed
• Mono: 13 total, 7 passed, 6 failed

Root Cause

The issue appears to be that Mono's reflection APIs return "inflated" generic types in stack frames, showing the concrete types that were used at runtime (string, int) instead of the generic type parameters (T, TVal) that CoreCLR preserves.

This affects:

• MethodBase.GetGenericArguments()
• Parameter type information from ParameterInfo.ParameterType
• Method names in dynamically generated assemblies

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response