Fix WebWorker template failing in published Blazor WASM apps

[ilonatommy]

Web Workers do not inherit the page's import map, causing fingerprinted asset resolution to fail.

During dotnet publish, Blazor WebAssembly apps fingerprint framework JavaScript files. The non-fingerprinted files do not exist in the published output. index.html contains an ES Module Import Map that maps the old names to the new ones. It did not fail on dotnet run (WebWorkerTemplate_CanInvokeMethods) because then we do not fingerprint.

Web Workers are separate JavaScript execution contexts. Per HTML spec they do not inherit parent page's import map. There is an issue with proposal of fixing it: whatwg/html#8173. but without much activity.

Description

Client reads the page's import map, resolves the fingerprinted URL, and passes it to the Worker via postMessage. Worker uses dynamic import() instead of static one.

This PR is adding tests that run published app.

Fixes #65820

[Copilot]

Pull request overview

Fixes the WebWorker project template so it works in published Blazor WebAssembly apps where framework JS files are fingerprinted and resolved via the page’s import map (which workers don’t inherit).

Changes:

• Switch worker startup from a static module import to an init message that provides the resolved dotnet.js URL, then dynamically import() it in the worker.
• Add client-side import map parsing to resolve the fingerprinted dotnet.js URL and send it to the worker during creation.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/ProjectTemplates/Web.ProjectTemplates/content/WebWorker-CSharp/wwwroot/dotnet-web-worker.js	Defers .NET runtime loading until an init message provides the correct dotnet.js URL; uses dynamic import.
src/ProjectTemplates/Web.ProjectTemplates/content/WebWorker-CSharp/wwwroot/dotnet-web-worker-client.js	Resolves dotnet.js via the document import map and posts it to the worker as part of initialization.