Blazor WASM ignores the Base Href when trying to fetch hot-reload script

[gfs]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The Hot-Reload script ignores the base href when being fetched resulting in a 404 if the base href is set to anything other than /.

Expected Behavior

Debugging with a base href set works as it did in .NET 5.0.

Steps To Reproduce

1. Create a new Blazor WASM application.
2. Change the base href.
3. Attempt to debug the project.
4. The application will fail to load because it fails to find the hot reload script.

• It does not work in both project launch and IIS express launch modes - however in IIS mode you will get the error in the browser, in project launch mode it doesn't get that far.

See https://github.com/gfs/BlazorWasmHotReloadFailure for an example project that demonstrates this behavior.

Exceptions (if any)

No response

.NET Version

6.0.101

Anything else?

Visual Studio Version 17.0.4

PS C:\Users\gstocco\GitHub\BlazorWasmHotReloadFailure> dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.101
 Commit:    ef49f6213a

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22000
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.101\

Host (useful for support):
  Version: 6.0.1
  Commit:  3a25a7f1cc

.NET SDKs installed:
  6.0.101 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Kebechet]

I have the same problem. Blazor hosted which have Blazor server pages on root / and client on /app.
And the hotreload.js is not able to load properly because of this.

Why it cant be fixed but it have to wait for .NET 7 ?

[keenam]

A workaround is to use dotnet run with --pathbase= as indicated in MSDN application.
However, this workaround has limitations when the app is used as reverse proxy to the other app for the development.

I also tried disabling hotReloadEnabled but it didn't help.
Running in Release build resolves this issue but this will slow down the development dramatically.

Failure to load hotload should be allowed to during development instead of halting.

Update:

Having hot reload option set to false bypasses. It wasn't obvious until this is set and build had to be cleaned first.

"hotReloadEnabled": false

I used with IIS Express with _wasm as the sub folder in the base href.

{
...
    "IIS Express": {
      "commandName": "IISExpress",
        "launchBrowser": true,
      "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_wasm/_framework/debug/ws-proxy?browser={browserInspectUri}",
        "environmentVariables": {
            "ASPNETCORE_ENVIRONMENT": "Development"
        },
      "hotReloadEnabled": false
    }
}

[gfs]

Hey @keenam,

Thanks for the extra info. Where did you add the hot reload false parameter? Is that in the launch.json configuration for the debug config?

[keenam]

@gfs

It's in the launchSettings.json
I will update more info to be clearer.

[mkArtakMSFT]

We think this is fixed in the upcoming .NET 7 preview 7 release. Can someone please give it a try when it ships and let us know if this is still an issue? Thanks!

[danroth27]

Closing as we believe this is addressed.