Repository navigation
Working WASM project migrated to .NET 10 - 'MONO interpreter: NIY encountered in method' or 'Your mono runtime and class libraries are out of sync' #121849
Description
Description
I originally posted as a comment on this other issue which seems related: #121840
I have now spent 3 days trying different combinations of settings in the .csproj and I always end up with one of the following errors.
This is an existing, mature project, using .NET 9 that has just been migrated to .NET 10. Right from the end of the migration, using exactly the same settings that used to work, we started getting errors caused by the trimmer. The project builds and runs successfully when running from within Visual Studio 2026 both in Debug and Release configurations.
Here are the original .csproj settings:
<TreatWarningsAsErrors>True</TreatWarningsAsErrors>
<!-- These are disabled because they are very noisy, but are left in as a reminder of the options that we have available -->
<EnableTrimAnalyzer>False</EnableTrimAnalyzer>
<SuppressTrimAnalysisWarnings>True</SuppressTrimAnalysisWarnings>
<!-- This works around issues with a published/release version, like missing constructors, etc.-->
<!-- TODO: we need to sort this out so that we can trim without causing issues -->
<!-- TODO: Our tests should also include the same trimming behaviour as our publishing -->
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
<PublishTrimmed>True</PublishTrimmed>
<RunAOTCompilation>False</RunAOTCompilation>
<!-- This option allows the trimming process to remove a considerable amount of code from the final binaries, further reducing the size.
See: https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/trimming-options?pivots=dotnet-7-0 -->
<InvariantGlobalization>True</InvariantGlobalization>
</PropertyGroup>
<ItemGroup>
<!-- This is required for our domain to work in the browser, as we need to deserialize immutable collections which do not have public constructors. These would otherwise be trimmed.-->
<TrimmerRootAssembly Include="System.Collections.Immutable" />
<!-- This is required for authentication to work in a published/release version: https://stackoverflow.com/a/68214821/257372 -->
<TrimmerRootAssembly Include="Microsoft.Authentication.WebAssembly.Msal" />
<TrimmerRootAssembly Include="System.Collections.Concurrent" />
</ItemGroup>
And here's the command we use to publish:
dotnet publish ..\UI\UI.csproj --configuration Release --output C:\MyPublishDirectory --verbosity m --tl:off
We then test the published artifacts by serving them locally using dotnet serve (something we started doing now in order to remove CDN and caching from the equation).
With those same settings we get the following runtime error:
MONO interpreter: NIY encountered in method BlazorApplicationInsights.IServiceCollectionExtensions:AddBlazorApplicationInsights (Microsoft.Extensions.DependencyInjection.IServiceCollection,System.Action`1<BlazorApplicationInsights.Models.Config>,System.Func`2<BlazorApplicationInsights.Interfaces.IApplicationInsights, System.Threading.Tasks.Task>,bool,System.Action`1<BlazorApplicationInsights.ApplicationInsightsLoggerOptions>)
dotnet.runtime.o0qy896u8v.js:3 [MONO] * Assertion: should not be reached at /__w/1/s/src/runtime/src/mono/mono/mini/interp/interp.c:4130
Error
at Mc (dotnet.runtime.o0qy896u8v.js:3:172283)
...
Module._mono_wasm_invoke_jsexport @ dotnet.native.1aocdz4mc7.js:6272
wn @ dotnet.runtime.o0qy896u8v.js:3
(anonymous) @ dotnet.runtime.o0qy896u8v.js:3
Vc @ dotnet.runtime.o0qy896u8v.js:3
await in Vc
callEntryPoint @ blazor.webassembly.66stpp682q.js:1
qt @ blazor.webassembly.66stpp682q.js:1
await in qt
Yt @ blazor.webassembly.66stpp682q.js:1
an @ blazor.webassembly.66stpp682q.js:1
value @ BlazorLoader.js:72
value @ AppController.jsx:211
s @ web.js:878
Te @ web.js:903
blazor.webassembly.66stpp682q.js:1 ExitStatus {name: 'ExitStatus', message: 'Program terminated with exit(1)', status: 1}
Since the error seems related to trimming or "wasm build native" my strategy has been to disable anything that dotnet publish might be doing differently to a Visual Studio build, which is clearly something. However, this doesn't seem to be documented anywhere and I'm left randomly trying things:
- Disabling AOT Compilation and WasmBuildNative (PublishAot, RunAOTCompilation and WasmBuildNative set to false) produces error "WasmApp.Common.targets(494,5): error : WasmBuildNative is required because RunAOTCompilation=false, but WasmBuildNative is alread y set to 'false'". I understand this is by design but I was desperate to disable anything that dotnet publish might be doing under the hood.
- Leaving WasmBuildNative untouched (defaults to true) and disabling BlazorWebAssemblyEnableLinking and WasmNativeRelinking produces the same error.
- All the above plus disabling trimming (false) results a different error (see below).
Your mono runtime and class libraries are out of sync.
blazor.webassembly.66stpp682q.js:1 The out of sync library is: System.Private.CoreLib.dll
blazor.webassembly.66stpp682q.js:1
blazor.webassembly.66stpp682q.js:1 When you update one from git you need to update, compile and install
blazor.webassembly.66stpp682q.js:1 the other too.
blazor.webassembly.66stpp682q.js:1 Do not report this as a bug unless you're sure you have updated correctly:
blazor.webassembly.66stpp682q.js:1 you probably have a broken mono install.
blazor.webassembly.66stpp682q.js:1 If you see other errors or faults after this message they are probably related
blazor.webassembly.66stpp682q.js:1 and you need to fix your mono install first.
blazor.webassembly.66stpp682q.js:1
blazor.webassembly.66stpp682q.js:1 Your mono runtime and class libraries are out of sync.
blazor.webassembly.66stpp682q.js:1 The out of sync library is: System.Private.CoreLib.dll
blazor.webassembly.66stpp682q.js:1
blazor.webassembly.66stpp682q.js:1 When you update one from git you need to update, compile and install
blazor.webassembly.66stpp682q.js:1 the other too.
blazor.webassembly.66stpp682q.js:1 Do not report this as a bug unless you're sure you have updated correctly:
blazor.webassembly.66stpp682q.js:1 you probably have a broken mono install.
blazor.webassembly.66stpp682q.js:1 If you see other errors or faults after this message they are probably related
blazor.webassembly.66stpp682q.js:1 and you need to fix your mono install first.
blazor.webassembly.66stpp682q.js:1 [ERROR] FATAL UNHANDLED EXCEPTION: Nested exception detected.
wt @ blazor.webassembly.66stpp682q.js:1
put_char @ dotnet.native.ywo0av6b5x.js:1369
write @ dotnet.native.ywo0av6b5x.js:1315
write @ dotnet.native.ywo0av6b5x.js:2824
doWritev @ dotnet.native.ywo0av6b5x.js:5361
_fd_write @ dotnet.native.ywo0av6b5x.js:5443
...
(anonymous) @ blazor.webassembly.66stpp682q.js:1
await in (anonymous)
Zt @ blazor.webassembly.66stpp682q.js:1
qt @ blazor.webassembly.66stpp682q.js:1
Yt @ blazor.webassembly.66stpp682q.js:1
an @ blazor.webassembly.66stpp682q.js:1
value @ BlazorLoader.js:72
value @ AppController.jsx:211
s @ web.js:878
Te @ web.js:903
blazor.webassembly.66stpp682q.js:1 Original Exception: at (wrapper managed-to-native) System.Threading.Interlocked.CompareExchange (object&,object&,object&,object&) [0x00000] in <2ce51f039573407794a9b71d8340c2cc>:0
wt @ blazor.webassembly.66stpp682q.js:1
put_char @ dotnet.native.ywo0av6b5x.js:1369
write @ dotnet.native.ywo0av6b5x.js:1315
write @ dotnet.native.ywo0av6b5x.js:2824
doWritev @ dotnet.native.ywo0av6b5x.js:5361
$mono_wasm_load_runtime @ dotnet.native.h9zhezurw2.wasm:0x22048e
...
Module._mono_wasm_load_runtime @ dotnet.native.ywo0av6b5x.js:6405
(anonymous) @ dotnet.runtime.o0qy896u8v.js:3
(anonymous) @ dotnet.runtime.o0qy896u8v.js:3
blazor.webassembly.66stpp682q.js:1 Uncaught (in promise) Error: Failed to start platform. Reason: [object Object]
I am now stuck without understanding what's going on or how to fix it.
Before you ask, I have tried to reproduce in a simpler project but haven't been able to :-)
Reproduction Steps
I'm afraid I haven't been able to create a minimal reproduction. A key piece of data is that the project was working fine before migrating to .NET 10. That's the only change.
Expected behavior
The application should execute successfully.
Actual behavior
Depending on the settings, one of the following errors:
- Your mono runtime and class libraries are out of sync
- MONO interpreter: NIY encountered in method
See the description for full details.
Regression?
Yes. This same project with these same settings works OK in .NET 9.
Known Workarounds
I wish!
Configuration
.NET: 10.0.100
Windows: 11
Standalone Blazor WASM
All browsers
Other information
Looks like it's related to trimming and AOT. And the fact that it doesn't look like they can be disabled for a dotnet publish makes it impossible to work around it.
Activity
oroztocil commentedon Nov 21, 2025
@rodolfograve Thank you for the report. Note that BlazorApplicationInsights is a third-party package that might need to be updated to support .NET 10.
@pavelsavara Could this be related to the changes we made for metrics?
dotnet-policy-service commentedon Nov 21, 2025
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.
rodolfograve commentedon Nov 21, 2025
Thank you, @oroztocil. Wouldn't any issues with a dependency show up in a "normal" Release build from within Visual Studio? This is the bit that's making it so hard for me: it all works if I run a Visual Studio build but then fails in an obscure way (at least from my perspective) when I use dotnet publish, and I have no clue what that difference is, how to make it disappear and ultimately fix the problem.
I was just now trying to get a deployable output by using dotnet build, MSBuild, etc. but apparently none of those generate the static files.
Any workarounds, temporary solutions, etc. are very welcome at this stage while a deeper investigation takes place.
rodolfograve commentedon Nov 21, 2025
Update: I have executed
dotnet workload updateanddotnet workload repair. I can see that "Workload version jumped from 10.0.100 to 10.0.100.1"... but this hasn't solved the issue. Still the same error messages either at build time or runtime as described above.dotnet --infooutput before the update was:After update + repair:
rodolfograve commentedon Nov 21, 2025
I also just tried
following something mentioned here #64049 but unfortunately it didn't make any difference.
pavelsavara commentedon Nov 21, 2025
No, this is some build issue. Most likely duplicate of #98690
@rodolfograve try to delete
bin/objfolders after any change to project files.rodolfograve commentedon Nov 21, 2025
Thanks, @pavelsavara. Adding a dotnet clean was one of the first things I did (see below). Unfortunately, that didn't make any difference.
However, right after pressing the "Submit" button on this comment I noticed that you explicitly said "delete bin/obj", not clean. So I ran:
and... it worked! #119382 is very cryptic. Would you mind providing a quick summary of what's going on and what scenarios are affected so that I (and others) can avoid this issue in the future?
pavelsavara commentedon Nov 21, 2025
Yes,
dotnet cleanis likely broken for same reasons as incremental. @maraf understands the details better, but it's complex topic.