Blazor WebAssembly: Warnings about dotnet.runtime.js and dotnet.native.js version mismatch with dotnet.js after publish

[Solbstr]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

After publishing a new version of a Blazor WebAssembly Hosted app (example: .NET 9.0.3 → 9.0.4), the browser console shows persistent mismatch warnings:

dotnet.runtime.qrl1fuqt3c.js:3 MONO_WASM: The version of dotnet.runtime.js 831d23e56149cd59c40fc00c7feb7c5334bd19c4 is different from the version of dotnet.js 80aa709f5d919c6814726788dc6dabe23e79e672!

dotnet.runtime.qrl1fuqt3c.js:3 MONO_WASM: The version of dotnet.native.js 831d23e56149cd59c40fc00c7feb7c5334bd19c4 is different from the version of dotnet.js 80aa709f5d919c6814726788dc6dabe23e79e672!

Even though the warnings appear, the application continues to function normally.

The root cause seems to be that dotnet.js is not fingerprinted during publish, so browsers aggressively cache an outdated version across deployments.

This mismatch does not immediately break the app, but could cause issues with larger version upgrades in the future.

Expected Behavior

There should be no version mismatch warnings in the browser console after publishing a new version.

Ideally, dotnet.js should be fingerprinted (e.g., /dotnet.[hash].js) during publish, just like dotnet.runtime.js and dotnet.native.js are.

This would prevent caching issues and ensure version consistency.

Steps To Reproduce

1. Publish a new version of a Blazor WebAssembly Hosted app (e.g., upgrade from .NET 9.0.3 to 9.0.4).
2. Visit the site without clearing browser cache.
3. Open browser DevTools (F12) and check the console.
4. Observe mismatch warnings for dotnet.runtime.js and dotnet.native.js compared to dotnet.js.

Exceptions (if any)

No unhandled exceptions.

Only console warnings are shown.
Application still runs successfully.

.NET Version

9.0.201

Anything else?

Suggestion: Please fingerprint dotnet.js during publish, similar to other WebAssembly runtime assets.

Alternatively, provide a built-in cache-busting mechanism for critical runtime files at startup.

This would avoid unnecessary confusion for developers and prevent potential app breakage in future upgrades.

Tested on:

• Chrome (latest)
• Edge (latest)
• Deployment server: IIS

[javiercn]

@Solbstr thanks for contacting us.

@maraf do you know anything about this?

[maraf]

@Solbstr Do you se <ImportMap /> component? Does the problem reproduce when browser cache is not in play (DevTools->Network->Disable cache; anonymous browser window; etc)?

[Solbstr]

@maraf

No, I do not see in my project. I am still using UseStaticFiles for serving static content.

Regarding the cache:

When I enabled "Disable cache" in DevTools -> Network and reloaded the page, the version mismatch warnings disappeared.

After disabling "Disable cache" again and reloading the page normally, the warnings remained gone.

This confirms that the mismatch warnings were caused by a stale (cached) version of dotnet.js.

The application otherwise works correctly, but the warnings only clear when the browser is forced to fetch fresh files.

[maraf]

@Solbstr Thank you for clarifying that!

They way to solve it by using <ImportMap /> component that generates an importmap including all Blazor and .NET framework scripts. Unfortunately, the component requires conversion to Blazor Web app, the guide is at https://learn.microsoft.com/en-us/aspnet/core/migration/70-80?view=aspnetcore-9.0&tabs=visual-studio#convert-a-hosted-blazor-webassembly-app-into-a-blazor-web-app.

As a workaround the loadBootResource callback can be used to modify the URL resources are loaded from https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/startup?view=aspnetcore-9.0#load-client-side-boot-resources.

[Solbstr]

@maraf

Thanks for the follow-up!

I’ve now completed the migration to a full Blazor Web App, including configuring MapStaticFiles() and loading assets via the Assets[] API. This ensures that all Blazor and .NET framework scripts (including dotnet.js, dotnet.runtime.js, and dotnet.native.js) are properly fingerprinted and cache-safe.

The mismatch warnings I originally reported are no longer present — the issue is fully resolved on my end. 🎉

When I first followed the migration guide back in November 2024, some parts of the ImportMap setup weren’t yet available or documented, so I was still using UseStaticFiles() with manually registered scripts. The missing step for me was switching to the new static asset pipeline introduced with .NET 9.

Appreciate your help and links to the official guidance!

[maraf]

@Solbstr Awesome. Thank you for confirmation!

I'm going to close the issue now. Feel free to reach back.