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

[thaystg]

I was able to reproduce the issue and check that this PR fixes the issue.

This is the same configuration used on Blazor.DevServer.
https://github.com/dotnet/aspnetcore/blob/579d547d708eb19f8b05b00f5386649d6dac7b6a/src/Components/WebAssembly/DevServer/src/blazor-devserver.runtimeconfig.json.in#L8C6-L8C32

Fixes: #88391

[ghost]

Tagging subscribers to this area: @thaystg
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I was able to reproduce the issue and check that this PR fixes the issue.

This is the same configuration used on Blazor.DevServer.
https://github.com/dotnet/aspnetcore/blob/579d547d708eb19f8b05b00f5386649d6dac7b6a/src/Components/WebAssembly/DevServer/src/blazor-devserver.runtimeconfig.json.in#L8C6-L8C32

Fixes: #88391

Author:	thaystg
Assignees:	-
Labels:	area-Debugger-mono
Milestone:	-

[thaystg]

@lewing can I backport it to .net6 and .net7?

[radical]

https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-environment-variables suggests that maybe DOTNET_ROLL_FORWARD is the one to use now? Maybe RollForward=LatestMajor?

[thaystg]

https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-environment-variables suggests that maybe DOTNET_ROLL_FORWARD is the one to use now? Maybe RollForward=LatestMajor?

I don't have any preference at all.
But I think that if DevServer runs in an environment BrowserDebugProxy should also run that is why I decided to use the same configuration that they use to avoid any weird error on running BrowserDebugProxy.
If you prefer environment variable I can open a PR on aspnetcore repo, if you prefer RollForward=LatestMajor here, I can also update the PR.

[radical]

Whatever is acceptable for blazor should be good for us too.

[radical]

The test failure shouldn't be related to this, right?

[ghost]

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

Issue Details

---

I was able to reproduce the issue and check that this PR fixes the issue.

This is the same configuration used on Blazor.DevServer.
https://github.com/dotnet/aspnetcore/blob/579d547d708eb19f8b05b00f5386649d6dac7b6a/src/Components/WebAssembly/DevServer/src/blazor-devserver.runtimeconfig.json.in#L8C6-L8C32

Fixes: #88391

Author:	thaystg
Assignees:	thaystg
Labels:	arch-wasm, area-Debugger-mono
Milestone:	-

[thaystg]

/backport to release/7.0-staging

[thaystg]

/backport to release/6.0-staging

[github-actions]

Started backporting to release/7.0-staging: https://github.com/dotnet/runtime/actions/runs/5576097797

[github-actions]

Started backporting to release/6.0-staging: https://github.com/dotnet/runtime/actions/runs/5576099118

[vitek-karas]

Please note that rollForwardOnNoCandidate is deprecated. The host has to support it for backward compat, but we may decide to remove it one day in the future. The recommended option is rollForward. In this case, since we're just building a normal app the best solution is to set RollForward=Major in your project file - which will correctly populate the runtimeconfig.json and so on.

[thaystg]

@mkArtakMSFT, I think this is an important information for you to change the DevServer behavior, then we also change the BrowserDebugProxy behavior. I really don't want to get a different behavior between them to avoid the customer to see an error only when trying to debug the app. I think we should start the change on DevServer side and then propagate the same behavior here.

[vitek-karas]

I want to make it clear that rollForwardOnNoCandidateFx=2 and rollForward=Major are functionally equivalent. You will not see differences in behavior (the implementation actually translates the former to the latter). But if we could, making the change to use RollFoward would be better - it's fully supported by SDK, unlike the old setting.

[thaystg]

#89960