Fix GetModule_ReturnsModule test failure on browser-wasm

[lewing]

The else branch added in PR #125080 assumed !HasAssemblyFiles implies NativeAOT, but browser-wasm also has !HasAssemblyFiles (since Assembly.Location is empty). On wasm (Mono), Module.Name returns the real DLL name ("System.Reflection.Context.Tests.dll"), not "<Unknown>", so the assertion fails.

Split the else branch to handle NativeAOT and wasm separately:

• NativeAOT: assert Module.Name == "<Unknown>"
• wasm/other: call GetModule(moduleName) and assert not null

Fixes #125245

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes a failing System.Reflection.Context test on browser-wasm by separating the previous !HasAssemblyFiles behavior into distinct expectations for NativeAOT vs wasm/other platforms, aligning assertions with runtime-specific Module.Name results.

Changes:

• Update GetModule_ReturnsModule to treat !HasAssemblyFiles as either NativeAOT (expect "<Unknown>") or non-NativeAOT (expect GetModule(name) succeeds).
• Keep the test unconditionally runnable while branching assertions per platform behavior.

[Copilot]

In the non-NativeAOT paths, both branches do the same thing (call GetModule(moduleName) and assert not null). This can be simplified to reduce duplication (e.g., handle IsNativeAot first, otherwise always assert GetModule is non-null), and the comment should be generalized since this else applies to any !HasAssemblyFiles && !IsNativeAot, not only browser-wasm.

[Copilot]

The comment says GetModule returns null on native AOT, but this branch only asserts moduleName is "". Either update the comment to match what’s being asserted, or add an assertion that _customAssembly.GetModule(moduleName) is null to validate the stated behavior.

Suggested change

	Assert.Equal("<Unknown>", moduleName);
	Assert.Equal("<Unknown>", moduleName);
	Module module = _customAssembly.GetModule(moduleName);
	Assert.Null(module);

[jkotas]

Is this valid for CoreCLR as well?

[lewing]

I have no idea, I'd just prefer people not commit red tests, we can revert #125080 and discuss it more

[jkotas]

Sure, I am just pointing out that this change is likely moving the red to a different configuration yet again.

I'd just prefer people not commit red tests, we can revert #125080 and discuss it more

The build analysis flagged this test on wasm as a known failure in #125080. The problem was that the matching pattern in #125051 that tracked the know failure was not specific enough. cc @matouskozak

[lewing]

Right, I wasn't intending on merging it on red, I opened the PR to hand off to the proper owner. I'm tired of tracking down red tests that were recently added and then become my problem.

[lewing]

@danmoseley we need tests that work for all the versions of the platforms including the outerloops can you take a look please.

[agocke]

Longer term we should have a plan for converging behavior, I.e. coreclr has a consistent behavior for these situations and I presume we will continue to use that behavior on wasm.

[danmoseley]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[danmoseley]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[danmoseley]

Are these two outerloops everything? If they are green too we can merge this?

And in terms of learnings for me, it's that before merging reflection-related test changes I should run various outerloops.

For the match pattern in #125051, I'm not sure what it should have been to be more specific.