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

[github-actions]

Backport of #88919 to release/7.0-staging

/cc @thaystg

Customer Impact

If the customer has only .net8 installed it's possible to run a BlazorWebassembly app targeting .net6/.net7, but it's not possible to debug it.
Fixes #88391

Testing

Installed .net8 in a computer, created a BlazorWebAssembly app and debugged it.

Risk

Low risk, only allowing the same version that is used to run DevServer to run BrowserDebugProxy.

[ghost]

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

Issue Details

---

Backport of #88919 to release/7.0-staging

/cc @thaystg

Customer Impact

Testing

Risk

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

• If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-Debugger-mono
Milestone:	-

[ghost]

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

Issue Details

---

Backport of #88919 to release/7.0-staging

/cc @thaystg

Customer Impact

If the customer has only .net8 installed it's possible to run a BlazorWebassembly app targeting .net6/.net7, but it's not possible to debug it.
Fixes #88391

Testing

Installed .net8 in a computer, created a BlazorWebAssembly app and debugged it.

Risk

Low risk, only allowing the same version that is used to run DevServer to run BrowserDebugProxy.

Author:	github-actions[bot]
Assignees:	-
Labels:	arch-wasm, area-Debugger-mono
Milestone:	-

[carlossanlop]

Friendly reminder: if you want this servicing fix to be included in the September 2023 Release, you'll have to merge this PR before August 14th.

[carlossanlop]

Also, if this is ready, please add the servicing-consider label so it shows up in the Tactics radar.

[jeffschwMSFT]

@vitek-karas can you take a look at the roll forward policy applied?

[vitek-karas]

As I commented on #88919 - the best solution is to set RollForward=Major in the project file. Using runtimeconfig.template.json in itself is something we should ideally not do (the SDK implementation of this is not very robust and it can potentially lead to problems in the future). And the rollForwardOnNoCandidateFx is deprecated because it can't express certain mechanisms we want.

[thaystg]

I really wouldn't like to get a different behavior between DevServer and BrowserDebugProxy to avoid the customer to see an error only when trying to debug the app. And DevServer is using exactly these settings. Do you recommend to also change this on AspnetCore repo?

Without this PR the customer that only has .net8 installed cannot debug an app targeting .net7 but can run an app targeting .net7.

[vitek-karas]

The functional effect of both of these settings is the same, it's more about what we want to support going forward and SDK's support for it. rollForwardOnNoCandidateFx is only recognized by the host, it has no SDK support. RollForward is fully supported by the SDK.

If it's too risky to change I don't mind the current solution - it will work. But we should try to change it going forward.

[thaystg]

I can do whatever you prefer, if you prefer:

1. I can open a PR changing it on main, and backport it to release/7.0 and release/6.0.
2. Or we can merge this behavior for release/7.0 and release/6.0 and on main I implement it the way you suggested.