After installing 10.0 RTM, publish 9.0 Blazor WebAssembly app, some errors "MONO_WASM: mono_wasm_load_runtime () failed" appears when go to the Counter page

[jinzhao1127]

REGRESSION INFO: Works well on 10.0 RC 1 + 9.0.306

INSTALL STEPS:

1. Install Latest 10.0 GA SDK from Release Tracker
2. Install the 9.0.306 SDK from https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/sdk-9.0.306-windows-x64-installer
3. Apply 10.0 GA Feed and do feed workaround

Platform

• Windows
• macOS
• Linux

Repro Steps

1. Open up a normal Command Prompt (Terminal)
2. Create a 9.0 Blazor Web App for WebAssembly

   dotnet new blazor -int WebAssembly  -f net9.0 -o wasm
   cd wasm/wasm
   

3. Publish the project with dotnet publish
4. Go to the publish folder and run dotnet wasm.dll.
5. Open the browser and go to the http://localhost:5000/counter
6. Open the browser developer console window

Actual Result

There is no any response and the console window contains some error

Error Log

dotnet.runtime.st3wwc8rqy.js:3 
 [MONO] * Assertion at /__w/1/s/src/mono/mono/metadata/assembly.c:2718, condition `<disabled>' not met

Error
    at Fc (dotnet.runtime.st3wwc8rqy.js:3:168832)
    at dotnet.native.21mns4qp4i.wasm:0xac91
    at dotnet.native.21mns4qp4i.wasm:0x43052
    at dotnet.native.21mns4qp4i.wasm:0x4105b
    at dotnet.native.21mns4qp4i.wasm:0x4117c
    at dotnet.native.21mns4qp4i.wasm:0x411bf
    at dotnet.native.21mns4qp4i.wasm:0x41192
    at dotnet.native.21mns4qp4i.wasm:0x8cf4
    at Module._mono_wasm_load_runtime [as mono_wasm_load_runtime] (dotnet.native.9ih887ebfz.js:8:114094)
    at dotnet.runtime.st3wwc8rqy.js:3:184838
dotnet.runtime.st3wwc8rqy.js:3 
 MONO_WASM: mono_wasm_load_runtime () failed [object Object]
dotnet.runtime.st3wwc8rqy.js:3 
 Uncaught (in promise) 
ExitStatus {name: 'ExitStatus', message: 'Program terminated with exit(1)', status: 1, silent: true}
dotnet.runtime.st3wwc8rqy.js:3 
 Uncaught (in promise) 
ExitStatus {name: 'ExitStatus', message: 'Program terminated with exit(1)', status: 1, silent: true}
blazor.web.js:1 
 Uncaught (in promise) Error: Failed to start platform. Reason: [object Object]
    at Hr (blazor.web.js:1:164967)
blazor.web.js:1 
 Uncaught (in promise) 
ExitStatus {name: 'ExitStatus', message: 'Program terminated with exit(1)', status: 1, silent: true}


Expected Result:
There is no any error when click counter button

Note:

1. This issue also reproduces on Blazor wasm Standalone app
2. This issue does not repro on Blazor Web Server app
3. This issue does not repro when dotnet run
4. This issue does not reproduce on 10.0 project
5. This issue does not reproduce on 8.0 project
6. This issue also reproduce when publish to Azure

[emmanuelpare]

Hi I got the same exact issue.. I tried to rollback my nugget package to Rrc-1 but still have the issue. Do I need to change a version in docker image? It was working fine with rc-1 before

[maraf]

@jinzhao1127 What is output of dotnet --info?

[emmanuelpare]

Here my dotnet --info... It work locally but When Iam packaging my docker image its failing... I guess mcr.microsoft.com/dotnet/sdk:10.0 is based on the faulty version... what version can I use to go back to RC-1?

.NET SDK:
Version: 10.0.100-rc.2.25502.107
Commit: 89c8f6a112
Workload version: 10.0.100-manifests.4d32cd9e
MSBuild version: 18.0.0-preview-25502-107+89c8f6a11

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26100
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\10.0.100-rc.2.25502.107\

.NET workloads installed:
[wasm-tools]
Installation Source: SDK 10.0.100-rc.2, VS 18.0.11111.16
Manifest Version: 10.0.100-rc.2.25502.107/10.0.100-rc.2
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100-rc.2\microsoft.net.workload.mono.toolchain.current\10.0.100-rc.2.25502.107\WorkloadManifest.json
Install Type: Msi

Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
Version: 10.0.0-rc.2.25502.107
Architecture: x64
Commit: 89c8f6a112

.NET SDKs installed:
10.0.100-rc.1.25451.107 [C:\Program Files\dotnet\sdk]
10.0.100-rc.2.25502.107 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Here is my docker file

Build stage

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src

RUN apt-get update &&
apt-get install -y python3 ca-certificates curl gnupg libatomic1 &&
dotnet workload install wasm-tools

COPY ["gcb-atlas/gcb-atlas.csproj", "gcb-atlas/"]
RUN dotnet restore "gcb-atlas/gcb-atlas.csproj"

COPY . .
WORKDIR "/src/gcb-atlas"
RUN dotnet build "gcb-atlas.csproj" -c Release -o /app/build

Publish stage

FROM build AS publish
RUN dotnet publish "gcb-atlas.csproj" -c Release -o /app/publish

Final stage

FROM alpine:latest

Install Nginx with Brotli module from Alpine packages

RUN apk add --no-cache nginx nginx-mod-http-brotli

WORKDIR /usr/share/nginx/html
COPY --from=publish /app/publish/wwwroot .
COPY gcb-atlas/nginx.conf /etc/nginx/nginx.conf

EXPOSE 8080
CMD ["nginx", "-g", "daemon off;"

[emmanuelpare]

Ok I changed my docker file with the following version: FROM mcr.microsoft.com/dotnet/sdk:10.0.100-rc.1 AS build and reverted nuget packages and its fixed

[rabarbers]

I had similar issue when upgrading visual studio insiders to version 11111.16. While googling for the problem i found this github page. Previous version of Visual Studio Insiders used .net 10 rc1. Latest version uses .net 10 rc2. After upgrading i run command in package manager console: "dotnet workload restore". This fixed the issue for me.

[benrad]

We are experiencing this issue, too. It appears that doing a dotnet publish fails to generate the project-specific wasm files normally found in the _framework directory (e.g. mynamespace.<fingerprint>.wasm).

This can be reproduced with a very simple Console.WriteLine("Hello World") POC with <Project Sdk="Microsoft.NET.Sdk.WebAssembly">. Simply switch between the rc.1 and rc.2 sdk versions in a global.json file, run dotnet publish, and check the contents of the _framework directory. Also note that the publish takes significantly less time with rc.2.

We are targeting .net 10.0, not 9.0 like the OP.

I thought this might have to do with AOT or trimming (we utilize both for our publish process), but disabling AOT and setting <PublishTrimmed> to false yields the same results.

[cameronbell97]

This has broken the publishing of a Blazor WASM project for me too, both from VS 2026 Insiders and from the dotnet CLI. Wiping the publish directory and running a publish from VS 2022 17.14.17 is my only solution currently

[Pvxtotal]

We are experiencing this issue, too. It appears that doing a dotnet publish fails to generate the project-specific wasm files normally found in the _framework directory (e.g. mynamespace.<fingerprint>.wasm).

This can be reproduced with a very simple Console.WriteLine("Hello World") POC with <Project Sdk="Microsoft.NET.Sdk.WebAssembly">. Simply switch between the rc.1 and rc.2 sdk versions in a global.json file, run dotnet publish, and check the contents of the _framework directory. Also note that the publish takes significantly less time with rc.2.

We are targeting .net 10.0, not 9.0 like the OP.

I thought this might have to do with AOT or trimming (we utilize both for our publish process), but disabling AOT and setting <PublishTrimmed> to false yields the same results.

I can confirm, I'm having the same issue with Lazy Loaded assemblies when publishing - I had to revert to .NET 9, this problem started with .NET 10 RC2

[jinzhao1127]

@jinzhao1127 What is output of dotnet --info?

C:\Users\v-zhajin>dotnet --info
.NET SDK:
 Version:           10.0.100
 Commit:            3bf0bbd389
 Workload version:  10.0.100-manifests.0cd60d2b
 MSBuild version:   18.0.0-preview-25514-102+3bf0bbd38

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22631
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.100\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
  Version:      10.0.0
  Architecture: x64
  Commit:       3bf0bbd389

.NET SDKs installed:
  9.0.306 [C:\Program Files\dotnet\sdk]
  10.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]