Blazor WASM: BrowserDebugHost.dll running from DevServer is missing roll-forward runtime policy #88391

seclerp · 2023-07-04T18:32:39Z

Description

When the default standalone Blazor WebAssembly project is starting, it's hosted using DevServer. Then, DevServer starts framework-dependent BrowserDebugHost.dll when it receives /debug/ws-proxy?... request. But, unlike DevServer itself, BrowserDebugHost.dll is missing configuration to roll forward on available runtime versions. This leads to situations when the user is able to start the application itself using dotnet run, but DevServer runs BrowserDebugHost using dotnet exec, which requires a specific runtime version by default.

Reproduction Steps

Uninstall .NET 6 SDK (if installed)
Install .NET 7 SDK or .NET 8 SDK
dotnet new blazorwasm -n TestApp1
Open the newly created project in VS Code
Change TFM from net7.0 to net6.0
Change NuGet versions from 7.0.8 to 6.0.19
dotnet build
Run the project with debugging enabled ("Launch and Debug Standalone WebAssembly App")

A preconfigured project can be found here.

Expected behavior

The app is running correctly, debugging is completely working as usual.

Actual behavior

The app starts, but debugging is completely broken, with a lot of exceptions in the console.

fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
      An unhandled exception has occurred while executing the request.
      System.InvalidOperationException: No output has been recevied from the application.
         at Microsoft.AspNetCore.Builder.DebugProxyLauncher.LaunchAndGetUrl(IServiceProvider serviceProvider, String devToolsHost)
         at Microsoft.AspNetCore.Builder.WebAssemblyNetDebugProxyAppBuilderExtensions.<>c.<<UseWebAssemblyDebugging>b__0_1>d.MoveNext()
      --- End of stack trace from previous location ---
         at Microsoft.AspNetCore.Builder.Extensions.MapMiddleware.InvokeCore(HttpContext context, PathString matchedPath, PathString remainingPath)
         at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddlewareImpl.Invoke(HttpContext context)

Regression?

No response

Known Workarounds

Since we can't control the process creation process for BrowserDebugHost.dll in DevServer, the only available option is to set the environment variable for DevServer and let it propagate to a child process with BrowserDebugHost.dll.

So DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX =2 or DOTNET_ROLL_FORWARD=Major should be used.

Options are from here.

Configuration

.NET SDK:
 Version:   8.0.100-preview.5.23303.2
 Commit:    3fe444af72

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.4
 OS Platform: Darwin
 RID:         osx.13-arm64
 Base Path:   /usr/local/share/dotnet/sdk/8.0.100-preview.5.23303.2/

.NET workloads installed:
 [maui]
   Installation Source: SDK 8.0.100-preview.5
   Manifest Version:    8.0.0-preview.5.8529/8.0.100-preview.5
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/8.0.100-preview.5/microsoft.net.sdk.maui/WorkloadManifest.json
   Install Type:        FileBased
 [wasm-tools-net7]
   Installation Source: SDK 8.0.100-preview.5
   Manifest Version:    8.0.0-preview.5.23280.8/8.0.100-preview.5
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/8.0.100-preview.5/microsoft.net.workload.mono.toolchain.net7/WorkloadManifest.json
   Install Type:        FileBased

Host:
  Version:      8.0.0-preview.5.23280.8
  Architecture: arm64
  Commit:       bc78804f5d

.NET SDKs installed:
  7.0.203 [/usr/local/share/dotnet/sdk]
  8.0.100-preview.4.23260.5 [/usr/local/share/dotnet/sdk]
  8.0.100-preview.5.23303.2 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0-preview.4.23260.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0-preview.5.23302.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0-preview.4.23259.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0-preview.5.23280.8 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Other information

A possible fix for such an issue is to add runtimeconfig.template.json for the BrowserDebugHost project itself, with a pre-configured roll-forward policy:

{
  "tfm": "net7.0",
  "rollForward": "Major"
}

Or using a project file:

<PropertyGroup>
  <RollForward>Major</RollForward>
</PropertyGroup>

The text was updated successfully, but these errors were encountered:

ghost · 2023-07-04T18:32:46Z

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

When the default standalone Blazor WebAssembly project is starting, it's hosted using DevServer. Then, DevServer starts framework-dependent BrowserDebugHost.dll when it receives /debug/ws-proxy?... request. But, unlike DevServer itself, BrowserDebugHost.dll is missing configuration to roll forward on available runtime versions. This leads to situations when the user is able to start the application itself using dotnet run, but DevServer runs BrowserDebugHost using dotnet exec, which requires a specific runtime version by default.

Reproduction Steps

Uninstall .NET 6 SDK (if installed)
Install .NET 7 SDK or .NET 8 SDK
dotnet new blazorwasm -n TestApp1
Open the newly created project in VS Code
Change TFM from net7.0 to net6.0
Change NuGet versions from 7.0.8 to 6.0.19
dotnet build
Run the project with debugging enabled ("Launch and Debug Standalone WebAssembly App")

A preconfigured project can be found here.

Expected behavior

The app is running correctly, debugging is completely working as usual.

Actual behavior

The app starts, but debugging is completely broken, with a lot of exceptions in the console.

fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
      An unhandled exception has occurred while executing the request.
      System.InvalidOperationException: No output has been recevied from the application.
         at Microsoft.AspNetCore.Builder.DebugProxyLauncher.LaunchAndGetUrl(IServiceProvider serviceProvider, String devToolsHost)
         at Microsoft.AspNetCore.Builder.WebAssemblyNetDebugProxyAppBuilderExtensions.<>c.<<UseWebAssemblyDebugging>b__0_1>d.MoveNext()
      --- End of stack trace from previous location ---
         at Microsoft.AspNetCore.Builder.Extensions.MapMiddleware.InvokeCore(HttpContext context, PathString matchedPath, PathString remainingPath)
         at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddlewareImpl.Invoke(HttpContext context)

Regression?

No response

Known Workarounds

Since we can't control the process creation process for BrowserDebugHost.dll in DevServer, the only available option is to set the environment variable for DevServer and let it propagate to a child process with BrowserDebugHost.dll.

So DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX =2 or DOTNET_ROLL_FORWARD=Major should be used.

Options are from here.

Configuration

.NET SDK:
 Version:   8.0.100-preview.5.23303.2
 Commit:    3fe444af72

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.4
 OS Platform: Darwin
 RID:         osx.13-arm64
 Base Path:   /usr/local/share/dotnet/sdk/8.0.100-preview.5.23303.2/

.NET workloads installed:
 [maui]
   Installation Source: SDK 8.0.100-preview.5
   Manifest Version:    8.0.0-preview.5.8529/8.0.100-preview.5
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/8.0.100-preview.5/microsoft.net.sdk.maui/WorkloadManifest.json
   Install Type:        FileBased
 [wasm-tools-net7]
   Installation Source: SDK 8.0.100-preview.5
   Manifest Version:    8.0.0-preview.5.23280.8/8.0.100-preview.5
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/8.0.100-preview.5/microsoft.net.workload.mono.toolchain.net7/WorkloadManifest.json
   Install Type:        FileBased

Host:
  Version:      8.0.0-preview.5.23280.8
  Architecture: arm64
  Commit:       bc78804f5d

.NET SDKs installed:
  7.0.203 [/usr/local/share/dotnet/sdk]
  8.0.100-preview.4.23260.5 [/usr/local/share/dotnet/sdk]
  8.0.100-preview.5.23303.2 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0-preview.4.23260.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0-preview.5.23302.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0-preview.4.23259.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0-preview.5.23280.8 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Other information

A possible fix for such an issue is to add runtimeconfig.template.json for the BrowserDebugHost project itself, with a pre-configured roll-forward policy:

{
  "tfm": "net7.0",
  "rollForward": "Major"
}

Or using a project file:

<PropertyGroup>
  <RollForward>Major</RollForward>
</PropertyGroup>

Author:	seclerp
Assignees:	-
Labels:	`area-Host`
Milestone:	-

ghost · 2023-07-06T00:28:52Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

When the default standalone Blazor WebAssembly project is starting, it's hosted using DevServer. Then, DevServer starts framework-dependent BrowserDebugHost.dll when it receives /debug/ws-proxy?... request. But, unlike DevServer itself, BrowserDebugHost.dll is missing configuration to roll forward on available runtime versions. This leads to situations when the user is able to start the application itself using dotnet run, but DevServer runs BrowserDebugHost using dotnet exec, which requires a specific runtime version by default.

Reproduction Steps

Uninstall .NET 6 SDK (if installed)
Install .NET 7 SDK or .NET 8 SDK
dotnet new blazorwasm -n TestApp1
Open the newly created project in VS Code
Change TFM from net7.0 to net6.0
Change NuGet versions from 7.0.8 to 6.0.19
dotnet build
Run the project with debugging enabled ("Launch and Debug Standalone WebAssembly App")

A preconfigured project can be found here.

Expected behavior

The app is running correctly, debugging is completely working as usual.

Actual behavior

The app starts, but debugging is completely broken, with a lot of exceptions in the console.

fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
      An unhandled exception has occurred while executing the request.
      System.InvalidOperationException: No output has been recevied from the application.
         at Microsoft.AspNetCore.Builder.DebugProxyLauncher.LaunchAndGetUrl(IServiceProvider serviceProvider, String devToolsHost)
         at Microsoft.AspNetCore.Builder.WebAssemblyNetDebugProxyAppBuilderExtensions.<>c.<<UseWebAssemblyDebugging>b__0_1>d.MoveNext()
      --- End of stack trace from previous location ---
         at Microsoft.AspNetCore.Builder.Extensions.MapMiddleware.InvokeCore(HttpContext context, PathString matchedPath, PathString remainingPath)
         at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddlewareImpl.Invoke(HttpContext context)

Regression?

No response

Known Workarounds

Since we can't control the process creation process for BrowserDebugHost.dll in DevServer, the only available option is to set the environment variable for DevServer and let it propagate to a child process with BrowserDebugHost.dll.

So DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX =2 or DOTNET_ROLL_FORWARD=Major should be used.

Options are from here.

Configuration

.NET SDK:
 Version:   8.0.100-preview.5.23303.2
 Commit:    3fe444af72

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.4
 OS Platform: Darwin
 RID:         osx.13-arm64
 Base Path:   /usr/local/share/dotnet/sdk/8.0.100-preview.5.23303.2/

.NET workloads installed:
 [maui]
   Installation Source: SDK 8.0.100-preview.5
   Manifest Version:    8.0.0-preview.5.8529/8.0.100-preview.5
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/8.0.100-preview.5/microsoft.net.sdk.maui/WorkloadManifest.json
   Install Type:        FileBased
 [wasm-tools-net7]
   Installation Source: SDK 8.0.100-preview.5
   Manifest Version:    8.0.0-preview.5.23280.8/8.0.100-preview.5
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/8.0.100-preview.5/microsoft.net.workload.mono.toolchain.net7/WorkloadManifest.json
   Install Type:        FileBased

Host:
  Version:      8.0.0-preview.5.23280.8
  Architecture: arm64
  Commit:       bc78804f5d

.NET SDKs installed:
  7.0.203 [/usr/local/share/dotnet/sdk]
  8.0.100-preview.4.23260.5 [/usr/local/share/dotnet/sdk]
  8.0.100-preview.5.23303.2 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0-preview.4.23260.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0-preview.5.23302.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0-preview.4.23259.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0-preview.5.23280.8 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Other information

A possible fix for such an issue is to add runtimeconfig.template.json for the BrowserDebugHost project itself, with a pre-configured roll-forward policy:

{
  "tfm": "net7.0",
  "rollForward": "Major"
}

Or using a project file:

<PropertyGroup>
  <RollForward>Major</RollForward>
</PropertyGroup>

Author:	seclerp
Assignees:	-
Labels:	`arch-wasm`, `area-Host`, `untriaged`
Milestone:	-

radical · 2023-07-06T00:29:15Z

cc @ilonatommy @thaystg

seclerp · 2023-07-17T13:51:11Z

Thanks!

dotnet-issue-labeler bot added the area-Host label Jul 4, 2023

ghost added the untriaged New issue has not been triaged by the area owner label Jul 4, 2023

seclerp changed the title ~~BrowserDebugHost.dll running from DevServer is missing roll-forward runtime policy~~ Blazor WASM: BrowserDebugHost.dll running from DevServer is missing roll-forward runtime policy Jul 4, 2023

radical added the arch-wasm WebAssembly architecture label Jul 6, 2023

radical added area-Debugger-mono and removed area-Host labels Jul 6, 2023

radical added this to the 8.0.0 milestone Jul 6, 2023

ghost removed the untriaged New issue has not been triaged by the area owner label Jul 6, 2023

lewing assigned ilonatommy and thaystg Jul 10, 2023

This was referenced Jul 10, 2023

Blazor Wasm debugging with a proxy #88051

Closed

Blazor WASM in VS2022 not work with 7.0.8 #88204

Closed

thaystg mentioned this issue Jul 14, 2023

[wasm][debugger] Using "rollForwardOnNoCandidateFx": 2 for BrowserDebugHost #88919

Merged

ghost added the in-pr There is an active PR which will close this issue when it is merged label Jul 14, 2023

thaystg closed this as completed in #88919 Jul 17, 2023

ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jul 17, 2023

thaystg mentioned this issue Jul 17, 2023

[release/7.0-staging] [wasm][debugger] Using "rollForwardOnNoCandidateFx": 2 for BrowserDebugHost #89004

Closed

ghost added the in-pr There is an active PR which will close this issue when it is merged label Jul 17, 2023

thaystg mentioned this issue Jul 17, 2023

[release/6.0-staging] [wasm][debugger] Using "RollForward": major for BrowserDebugHost #89003

Merged

ghost added in-pr There is an active PR which will close this issue when it is merged and removed in-pr There is an active PR which will close this issue when it is merged labels Aug 3, 2023

thaystg mentioned this issue Aug 3, 2023

[release/7.0-staging] [wasm][debugger] Using "RollForward": major for BrowserDebugHost #89962

Merged

ghost removed the in-pr There is an active PR which will close this issue when it is merged label Aug 14, 2023

ghost locked as resolved and limited conversation to collaborators Sep 13, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Blazor WASM: BrowserDebugHost.dll running from DevServer is missing roll-forward runtime policy #88391

Blazor WASM: BrowserDebugHost.dll running from DevServer is missing roll-forward runtime policy #88391

seclerp commented Jul 4, 2023 •

edited

Loading

ghost commented Jul 4, 2023

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

ghost commented Jul 6, 2023

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

radical commented Jul 6, 2023

seclerp commented Jul 17, 2023

Blazor WASM: BrowserDebugHost.dll running from DevServer is missing roll-forward runtime policy #88391

Blazor WASM: BrowserDebugHost.dll running from DevServer is missing roll-forward runtime policy #88391

Comments

seclerp commented Jul 4, 2023 • edited Loading

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

ghost commented Jul 4, 2023

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

ghost commented Jul 6, 2023

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

radical commented Jul 6, 2023

seclerp commented Jul 17, 2023

seclerp commented Jul 4, 2023 •

edited

Loading