Blazor WebAssembly fails in Chrome Extensions (Manifest V3) due to reserved _framework folder and hash validation

[Jackhammer88]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When attempting to use a Blazor WebAssembly application as part of a Chrome Extension (Manifest V3), the extension fails to load because Chrome disallows file or directory names beginning with an underscore (_). Blazor relies on a folder named _framework for its runtime, resources, and for dynamic module imports (e.g., dotnet.js). Furthermore, the blazor.boot.json file contains precomputed hashes for these resources which depend on the folder name.

Renaming the _framework folder manually (e.g., to blazor_framework) causes the hashes to mismatch and prevents the runtime from loading. Overriding the resource base path via window.__blazorBoot.bootResourceBase is insufficient since the internal logic and dynamic imports are hard-coded to reference _framework.

Expected Behavior

It should be possible to deploy a Blazor WebAssembly application within a Chrome Extension. Either Blazor should allow for configuring a different runtime resource folder name (with corresponding hash recalculation) or provide an alternative mechanism for overriding the base path for resources so that it can work within the constraints of Chrome Extension Manifest V3.

Steps To Reproduce

1. Create a new Blazor WebAssembly project.
2. Configure the project to be used as a Chrome Extension (Manifest V3).
3. Load the extension in Chrome.
4. Observe errors such as:
   • "Cannot load extension with file or directory name _framework"
   • "Failed to fetch dynamically imported module: chrome-extension://.../_framework/dotnet.js"

Exceptions (if any)

No response

.NET Version

9.0.101

Anything else?

No response

[javiercn]

@Jackhammer88 thanks for contacting us.

This is not something we currently support.