[Blazor] Add version-based cache busting to dotnet.js import statements

[Copilot]

This PR adds cache busting functionality to the dotnet.js import statements in Blazor WebAssembly applications to ensure browsers don't use stale cached versions when the file has been updated.

Changes Made

Modified /src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts to add version-based cache busting to dotnet.js imports:

1. Version-based cache busting: Uses a static version identifier 8.0.19 instead of dynamic timestamps
2. Proper URL manipulation: Uses URL object and URLSearchParams for robust parameter handling
3. Preserves existing parameters: Only adds v=8.0.19 if no v parameter is already present
4. Maintains custom loader compatibility: Preserves original behavior for custom resource loaders

Implementation Details

• Uses new URL(src, document.baseURI) to properly construct the absolute URL
• Uses URLSearchParams.has('v') to check for existing version parameters
• Uses URLSearchParams.set('v', '8.0.19') to add version when needed
• Applied only to the direct import path, not to custom resource loaders
• Ensures browsers bypass cache and download the latest version of dotnet.js

Example

Before:

const absoluteSrc = (new URL(src, document.baseURI)).toString();
return await import(/* webpackIgnore: true */ absoluteSrc);

After:

const absoluteUrl = new URL(src, document.baseURI);
if (!absoluteUrl.searchParams.has('v')) {
  absoluteUrl.searchParams.set('v', '8.0.19');
}
const absoluteSrc = absoluteUrl.toString();
return await import(/* webpackIgnore: true */ absoluteSrc);

This ensures each import gets a versioned URL like _framework/dotnet.js?v=8.0.19, forcing browsers to bypass cache when dotnet.js has been updated, while respecting any existing version parameters that may have been set by custom loaders.

Fixes #63161.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[dotnet-policy-service]

Greetings human! You've submitted a PR that modifies code that is shared with https://github.com/dotnet/runtime . Please make sure you synchronize this code with the changes in that repo!

[javiercn]

@copilot I rebased on top of release/8.0, but now you need to fix the problems

[Copilot]

@copilot I rebased on top of release/8.0, but now you need to fix the problems

Fixed the merge conflicts after the rebase to release/8.0. The cache busting functionality has been properly merged and now correctly applies timestamp query parameters to both the loadBootResource call and the import statement while maintaining compatibility with custom resource loaders. Commit: acd0e32

[Copilot]

Pull Request Overview

This PR implements version-based cache busting for dotnet.js imports in Blazor WebAssembly applications to prevent browsers from using stale cached versions when the framework has been updated.

Key Changes:

• Adds a static version parameter (v=8.0.19) to dotnet.js import URLs
• Uses proper URL manipulation with URL and URLSearchParams APIs
• Only adds versioning when no existing version parameter is present

[Copilot]

The hardcoded version '8.0.19' should be extracted to a constant or configuration value to make it easier to maintain and update across releases.

Suggested change

	absoluteUrl.searchParams.set('v', '8.0.19');
	absoluteUrl.searchParams.set('v', DOTNET_JS_VERSION);

[pavelsavara]

I think dotnet.js changes with the used runtime pack Nuget and with installed version of the wasm workload.
This would need some MSBuild magic, not just a constant

[javiercn]

This is a one-time fix to help alleviate the problem for the people currently facing it in 8.0. Given how transient the nature of this problem is (you have to get an old version, then a new version) I don't plan on building any more complex machinery for this.

In fact, since this is already fixed in 9.0 for hosted scenarios and 10.0, I don't necessarily believe we need to do anything more, but since the change is simple, I'm willing to consider this for a patch. I wouldn't do a fix any more complex than this

[pavelsavara]

I see

[maraf]

Should we do it only in case there is no custom loadBootResource? Can adding a query string parameter break something?

[javiercn]

I wouldn't worry about it, it's very unlikely that a query string breaks anything, but I don't mind commanding our silicon-based coworker to make that change.