Description
Summary
A Blazor WebAssembly application targeting .NET 10 publishes successfully, but the published app crashes very early at runtime only when built/published in Release.
The same codebase published in Debug gets past WebAssembly runtime startup and continues into normal application initialization.
This looks like a Release-only WebAssembly runtime/startup pipeline issue rather than an application-level issue.
Environment
OS: Windows x64
OS version: 10.0.26200
.NET SDK: 10.0.300
MSBuild: 18.6.3
.NET host/runtime: 10.0.8
wasm-tools workload installed
Aspire CLI in solution environment: 13.3.5+70b33bcb5f64c75e3ab6f57616545f35bd43dc81
Packages involved
Microsoft.AspNetCore.Components.WebAssembly: 10.0.8
Microsoft.AspNetCore.Components.WebAssembly.Authentication: 10.0.8
Microsoft.AspNetCore.Components.WebAssembly.Server: 10.0.8
Microsoft.AspNetCore.SignalR.Client: 10.0.8
Microsoft.EntityFrameworkCore: 10.0.8
The app also uses ABP 10.4.0 and Autofac 9.1.0, but the failure appears to happen before normal application initialization completes.
Debug vs Release behavior
This is the strongest signal in the investigation:
Debug publish does not fail with the WebAssemblyHostConfiguration VTable error.
Debug publish gets past runtime startup and proceeds into later application initialization.
In this environment, Debug later fails on an expected CORS/network call during ABP initialization, but that happens much later and confirms that runtime startup itself succeeds in Debug.
Additional investigation already done
Static config/resources
appsettings.json and appsettings.Development.json are served with HTTP 200.
JSON content is valid.
No bootstrap 4xx/5xx errors were found that would explain the crash.
Package alignment
Microsoft ASP.NET/Blazor/EF package versions were aligned from 10.0.7 to 10.0.8 during investigation.
The Release startup failure remained unchanged.
deps.json check
No duplicate package versions were found in the published deps.json.
Startup instrumentation
Program.Main was instrumented to log full exception trees.
The Release failure still occurs too early to produce an application-level root cause pointing to user code.
Release without AOT
Forcing a Release publish with RunAOTCompilation=false changes the failure mode instead of fixing it.
In that configuration, the app crashes deeper in the WASM runtime with a fatal nested exception around:
mono_wasm_load_runtime() failed
System.AppContext.Setup
System.Collections.Generic.EqualityComparer.get_Default
System.Threading.Interlocked.CompareExchange
That suggests the problem is in the Release WebAssembly runtime/codegen/startup path rather than only in the application or ABP code.
Why this seems runtime-related
Release publish crashes in WebAssembly startup before normal app initialization.
Debug publish gets past the runtime startup phase.
Release no-AOT changes the failure into a lower-level mono_wasm_load_runtime crash rather than resolving it.
Reproduction Steps
Repro steps
Publish the host project in Release:
dotnet publish src/Pricose.Tramites.Blazor/Pricose.Tramites.Blazor.csproj -c Release -o src/Pricose.Tramites.Blazor/bin/Release/net10.0/publish
Run the published executable locally:
dotnet Pricose.Tramites.Blazor.dll
Open the app in a browser:
ManagedError: AggregateException_ctor_DefaultMessage
(VTable setup of type Microsoft.AspNetCore.Components.WebAssembly.Hosting.WebAssemblyHostConfiguration failed)
Check the browser console.
Actual result
The Release-published app fails very early during WebAssembly startup with:
The UI shows the generic Blazor fatal startup error and the app does not proceed.
Expected result
The Release-published app should start successfully, same as the Debug-published app.
Expected behavior
The Release-published Blazor WebAssembly app should start successfully and behave the same as the Debug-published app with respect to runtime startup.
Specifically:
WebAssembly runtime initialization should complete without fatal startup exceptions.
No error like VTable setup of type Microsoft.AspNetCore.Components.WebAssembly.Hosting.WebAssemblyHostConfiguration failed should be thrown.
The app should proceed to normal application initialization and render the UI.
Actual behavior
Actual result
The Release-published app crashes during WebAssembly startup with:
ManagedError: AggregateException_ctor_DefaultMessage
(VTable setup of type Microsoft.AspNetCore.Components.WebAssembly.Hosting.WebAssemblyHostConfiguration failed)
The application does not reach normal startup.
Expected result
The Release-published app should start successfully, same as Debug publish, and proceed into application initialization.
Important comparison: Debug publish vs Release publish
If I publish the same app in Debug and run it locally, it does not fail with the WebAssemblyHostConfiguration VTable error.
Regression?
No response
Known Workarounds
No response
Configuration
Environment
OS: Windows x64
OS version: 10.0.26200
.NET SDK: 10.0.300
MSBuild: 18.6.3
.NET host/runtime: 10.0.8
wasm-tools workload installed
Aspire CLI in solution environment: 13.3.5+70b33bcb5f64c75e3ab6f57616545f35bd43dc81
Packages involved
Microsoft.AspNetCore.Components.WebAssembly: 10.0.8
Microsoft.AspNetCore.Components.WebAssembly.Authentication: 10.0.8
Microsoft.AspNetCore.Components.WebAssembly.Server: 10.0.8
Microsoft.AspNetCore.SignalR.Client: 10.0.8
Microsoft.EntityFrameworkCore: 10.0.8
The app also uses ABP 10.4.0 and Autofac 9.1.0, but the failure appears to happen before normal application initialization completes
Relevant project settings
The client project already has the common Release/WASM suspects disabled:
TargetFramework: net10.0
PublishTrimmed: false
TrimMode: none
IsTrimmable: false
WasmEnableRuntimeRelinking: false
BlazorCacheBootResources: false
BlazorWebAssemblyLoadAllGlobalizationData: true
InvariantGlobalization: false
Other information
Attached diagnostics:
release-wasm.binlog: Release publish build log where the startup failure reproduces.
debug-wasm.binlog: Debug publish build log from the same codebase/environment, used as baseline comparison.
Both logs were generated on the same machine with .NET SDK 10.0.300 and runtime 10.0.8.
binlog.zip
Description
Summary
A Blazor WebAssembly application targeting .NET 10 publishes successfully, but the published app crashes very early at runtime only when built/published in Release.
The same codebase published in Debug gets past WebAssembly runtime startup and continues into normal application initialization.
This looks like a Release-only WebAssembly runtime/startup pipeline issue rather than an application-level issue.
Environment
OS: Windows x64
OS version: 10.0.26200
.NET SDK: 10.0.300
MSBuild: 18.6.3
.NET host/runtime: 10.0.8
wasm-tools workload installed
Aspire CLI in solution environment: 13.3.5+70b33bcb5f64c75e3ab6f57616545f35bd43dc81
Packages involved
Microsoft.AspNetCore.Components.WebAssembly: 10.0.8
Microsoft.AspNetCore.Components.WebAssembly.Authentication: 10.0.8
Microsoft.AspNetCore.Components.WebAssembly.Server: 10.0.8
Microsoft.AspNetCore.SignalR.Client: 10.0.8
Microsoft.EntityFrameworkCore: 10.0.8
The app also uses ABP 10.4.0 and Autofac 9.1.0, but the failure appears to happen before normal application initialization completes.
Debug vs Release behavior
This is the strongest signal in the investigation:
Debug publish does not fail with the WebAssemblyHostConfiguration VTable error.
Debug publish gets past runtime startup and proceeds into later application initialization.
In this environment, Debug later fails on an expected CORS/network call during ABP initialization, but that happens much later and confirms that runtime startup itself succeeds in Debug.
Additional investigation already done
Static config/resources
appsettings.json and appsettings.Development.json are served with HTTP 200.
JSON content is valid.
No bootstrap 4xx/5xx errors were found that would explain the crash.
Package alignment
Microsoft ASP.NET/Blazor/EF package versions were aligned from 10.0.7 to 10.0.8 during investigation.
The Release startup failure remained unchanged.
deps.json check
No duplicate package versions were found in the published deps.json.
Startup instrumentation
Program.Main was instrumented to log full exception trees.
The Release failure still occurs too early to produce an application-level root cause pointing to user code.
Release without AOT
Forcing a Release publish with RunAOTCompilation=false changes the failure mode instead of fixing it.
In that configuration, the app crashes deeper in the WASM runtime with a fatal nested exception around:
mono_wasm_load_runtime() failed
System.AppContext.Setup
System.Collections.Generic.EqualityComparer.get_Default
System.Threading.Interlocked.CompareExchange
That suggests the problem is in the Release WebAssembly runtime/codegen/startup path rather than only in the application or ABP code.
Why this seems runtime-related
Release publish crashes in WebAssembly startup before normal app initialization.
Debug publish gets past the runtime startup phase.
Release no-AOT changes the failure into a lower-level mono_wasm_load_runtime crash rather than resolving it.
Reproduction Steps
Repro steps
Publish the host project in Release:
dotnet publish src/Pricose.Tramites.Blazor/Pricose.Tramites.Blazor.csproj -c Release -o src/Pricose.Tramites.Blazor/bin/Release/net10.0/publish
Run the published executable locally:
dotnet Pricose.Tramites.Blazor.dll
Open the app in a browser:
ManagedError: AggregateException_ctor_DefaultMessage
(VTable setup of type Microsoft.AspNetCore.Components.WebAssembly.Hosting.WebAssemblyHostConfiguration failed)
Check the browser console.
Actual result
The Release-published app fails very early during WebAssembly startup with:
The UI shows the generic Blazor fatal startup error and the app does not proceed.
Expected result
The Release-published app should start successfully, same as the Debug-published app.
Expected behavior
The Release-published Blazor WebAssembly app should start successfully and behave the same as the Debug-published app with respect to runtime startup.
Specifically:
WebAssembly runtime initialization should complete without fatal startup exceptions.
No error like VTable setup of type Microsoft.AspNetCore.Components.WebAssembly.Hosting.WebAssemblyHostConfiguration failed should be thrown.
The app should proceed to normal application initialization and render the UI.
Actual behavior
Actual result
The Release-published app crashes during WebAssembly startup with:
ManagedError: AggregateException_ctor_DefaultMessage
(VTable setup of type Microsoft.AspNetCore.Components.WebAssembly.Hosting.WebAssemblyHostConfiguration failed)
The application does not reach normal startup.
Expected result
The Release-published app should start successfully, same as Debug publish, and proceed into application initialization.
Important comparison: Debug publish vs Release publish
If I publish the same app in Debug and run it locally, it does not fail with the WebAssemblyHostConfiguration VTable error.
Regression?
No response
Known Workarounds
No response
Configuration
Environment
OS: Windows x64
OS version: 10.0.26200
.NET SDK: 10.0.300
MSBuild: 18.6.3
.NET host/runtime: 10.0.8
wasm-tools workload installed
Aspire CLI in solution environment: 13.3.5+70b33bcb5f64c75e3ab6f57616545f35bd43dc81
Packages involved
Microsoft.AspNetCore.Components.WebAssembly: 10.0.8
Microsoft.AspNetCore.Components.WebAssembly.Authentication: 10.0.8
Microsoft.AspNetCore.Components.WebAssembly.Server: 10.0.8
Microsoft.AspNetCore.SignalR.Client: 10.0.8
Microsoft.EntityFrameworkCore: 10.0.8
The app also uses ABP 10.4.0 and Autofac 9.1.0, but the failure appears to happen before normal application initialization completes
Relevant project settings
The client project already has the common Release/WASM suspects disabled:
TargetFramework: net10.0
PublishTrimmed: false
TrimMode: none
IsTrimmable: false
WasmEnableRuntimeRelinking: false
BlazorCacheBootResources: false
BlazorWebAssemblyLoadAllGlobalizationData: true
InvariantGlobalization: false
Other information
Attached diagnostics:
release-wasm.binlog: Release publish build log where the startup failure reproduces.
debug-wasm.binlog: Debug publish build log from the same codebase/environment, used as baseline comparison.
Both logs were generated on the same machine with .NET SDK 10.0.300 and runtime 10.0.8.
binlog.zip