WasmFingerprintAssets false breaks type/value information in WASM debugging

[ArcadeMode]

Description

I have found that the build property WasmFingerprintAssets has been the cause of my severely impaired debugging experience on a WASM Browser App (SDK Microsoft.NET.Sdk.WebAssembly).

Stepping works somehow, control flow etc reflects fine, but anything related to types or locals is showing the error below. I have not been able to find any sensible logging explaining why, I managed to find this by stripping my solution down step by step.

The browser console contains the following message, a couple dozen times.

Reproduction Steps

A minimal repro that i verified on a sample project:

1. Download the WASMBrowserAppImportExportInterop sample project
2. Add <WasmFingerprintAssets>false</WasmFingerprintAssets> to the .csproj
3. Rebuild
4. Launch a debugging session from Visual Studio (I used 2026)

Expected behavior

The debugging experience remains the same with or without the WasmFingerprintAssets property set.

Actual behavior

Locals and type information is not available during debugging. Stepping still works.
Anything like a (quick)watch of local inspection attempt results in the message Internal error in the C# compiler.

Regression?

Known Workarounds

Keep WasmFingerprintAssets set to true resolves the debugging issues.

Configuration

Built with the latest .NET 10.0.100 SDK bundle. Running on the Mono wasm runtime.
Windows 10/11 same problem.

I presume this is not specific to my machine configuration.

Its happened in Chrome 142.0.7444.176

Other information

No response

[dotnet-policy-service]

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

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

I guess this is somehow related to loaderHelpers._loaded_files and INTERNAL.mono_wasm_get_loaded_files()

[pavelsavara]

The error is from

runtime/src/mono/mono/component/debugger-agent.c

Lines 2041 to 2043 in a9d1ab6

	// FIXME: error handling
	dbg_lock ();
	g_assert (id > 0 && GINT_TO_UINT(id) <= ids [type]->len);

It would be great to see the whole stack trace.

@ArcadeMode Could you please recompile the app with wasm workload and

<PropertyGroup>
  <WasmNativeDebugSymbols>true</WasmNativeDebugSymbols>
  <WasmNativeStrip>false</WasmNativeStrip>
</PropertyGroup>

and capture the native stack trace again ?

Thanks!

[pavelsavara]

Is this trying to guess assembly name from URL (with fingerprint) ?

runtime/src/mono/browser/debugger/BrowserDebugProxy/MonoProxy.cs

Lines 150 to 155 in a9d1ab6

	if (args["url"]?.ToString()?.Contains("/_framework/") == true) //is from dotnet runtime framework
	{
	if (Contexts.TryGetCurrentExecutionContextValue(sessionId, out ExecutionContext context))
	context.FrameworkScriptList.Add(args["scriptId"].Value<int>());
	}
	return false;

[maraf]

The piece that tries to guess assembly name based on fingerprint is in https://github.com/dotnet/runtime/pull/103755/changes#diff-e11dabfb758c8f0b3b1dae36ce80d16749918b5fd6511f4226f7e98554f01676 (DebugStore.cs). It is for the older debugger. I'm not sure about the new debugger