[Blazor] Error page support for Server Side Rendered Razor Component Applications

[javiercn]

Description

Adds support for Error pages to Blazor Web application.

• Includes a small change to the ExceptionHandler middleware to support Blazor Web scenarios.
• Includes a change in Blazor Web to account for error handling scenarios and disable streaming rendering and interactivity.
• Includes changes to the Blazor Web template to add an Error page similar to the one in MVC and Razor pages templates.

Fixes #49853, #49854

Customer Impact

• Customers won't be able to see errors in Blazor Web Applications without having to rely on MVC or Razor Pages for it,
  which adds significant complexity to their setup.

Regression?

• Yes
• No

Risk

• High
• Medium
• Low

• If customers hit any issues, we will be able to tell them to simply remove the ErrorPage.razor page from their projects. Luckily, we will have a little bit of time to address any critical feedback in case such comes up. As of right now, this change has been validated and it works.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[SteveSandersonMS]

Looks fantastic. I guess what remains is:

• E2E tests
• Update project template

[Tratcher]

This seems potentially double edged. While Blazor requires a new scope, other components may be expecting the original scope, or the parent / request scope.

If you turn this on by default and run all the CI tests, does anything fail?

[javiercn]

This seems potentially double edged. While Blazor requires a new scope, other components may be expecting the original scope, or the parent / request scope.

If you turn this on by default and run all the CI tests, does anything fail?

We can consider the error handling path "a separate request" the moment we send it down the pipeline. In that sense I don't think it'll be common for a component to fail in that situation, as it is "really hard" to distinguish that request from a regular request.

What I mean by that, is that I expect most components to be completely ignorant of the new scope and behave in the same way as if it was the original request scope.

To add to this, I turned on the create new scope by default, and I couldn't see any test fail outside of our existing flaky tests. In any case, as @SteveSandersonMS was quick to mention, this is something that users opt-in to, so it should not impact any existing app.

[javiercn]

@Tratcher any other feedback before this goes in?

[Tratcher]

To add to this, I turned on the create new scope by default, and I couldn't see any test fail outside of our existing flaky tests. In any case, as @SteveSandersonMS was quick to mention, this is something that users opt-in to, so it should not impact any existing app.

If we expect it to just work then we should turn it on by default and leave the option for opting out. Users hate having to discover settings to make things work.

[ghost]

Hi @javiercn. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[ghost]

Hi @javiercn. This PR was just approved to be included in the upcoming servicing release. Somebody from the @dotnet/aspnet-build team will get it merged when the branches are open. Until then, please make sure all the CI checks pass and the PR is reviewed.

[wtgodbe]

@javiercn can you retarget this to the rc2 branch & confirm the test failures are unrelated?

[SteveSandersonMS]

Great!