Improve Blazor project template

[halter73]

Use consistent code style in Blazor project templates

• Removed usage of top-level statements in client project if "Do not use top-level statements" is selected
• Removed extra "@" in @render-mode values
• Always use typeof(Namespace._Imports).Assembly instead of typeof(Counter).Assembly so the compilation does not break when the sample Counter component is removed, and so the code is more consistent with how it is when no sample content is generated
• Added Account/AccessDenied endpoint to individual auth option to match Identity UI razor pages. This is shown when the user is authenticated but unauthorized by default.

Fixes #52079
Fixes #52084
Fixes #52167

Customer Impact

In addition to not using top-level statements when the customer requests that we don't, this improves code style consistency within the Blazor project template and with the Blazor docs.

Regression?

• Yes
• No

Risk

• High
• Medium
• Low

These are small stylistic changes to the Blazor project templates.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[ghost]

Hi @halter73. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document.
Otherwise, please add tell-mode label.

[halter73]

@guardrex Regarding the following from #51084

Second ❓: WRT the logic for finding the .Client project assembly ...

#if (UseWebAssembly && SampleContent)
    .AddAdditionalAssemblies(typeof(Counter).Assembly);
#elif (UseWebAssembly)
   .AddAdditionalAssemblies(typeof(BlazorWeb_CSharp.Client._Imports).Assembly);
#endif

I don't see why the latter _Imports file-based approach isn't adopted even if sample content is present. After all, even the empty solution (no sample pages) has an _Imports file. As soon as the dev 🔪 out the Counter component because any production app isn't going to keep it, it will 💥. Many new devs and new-to-Blazor devs won't know the second approach for the _Imports file off the top of their head.

I don't have a huge preference one way or the other. I think @SteveSandersonMS chose Counter initially, and then I later added _Imports for the non-sample case. I left it as Counter for the default case because it does look better, but if everyone is okay with changing it to always use _Imports, I can do that as part of this PR.

[halter73]

Unlike the server template, this does not have an accessibility modifier. Neither does the Main method. I would have made both the class and public like we do for the server project, but this made the @typeof(Program).Assembly reference in Routes.razor ambiguous.

aspnetcore/src/ProjectTemplates/Web.ProjectTemplates/content/BlazorWeb-CSharp/BlazorWeb-CSharp/Components/Routes.razor

Line 5 in d8acc61

<Router AppAssembly="@typeof(Program).Assembly" AdditionalAssemblies="new[] { typeof(Client._Imports).Assembly }">

I could change that to be @typeof(BlazorWeb_CSharp.Program).Assembly instead and make this public. And then only qualify it when you've disabled top level statements.

Does anyone prefer that, or is everyone fine the way it is?

[danroth27]

@halter73 Can you update Routes.razor as well to remove the unnecessary leading @ chars?:

<Router AppAssembly="typeof(Program).Assembly">
    <Found Context="routeData">
        <RouteView RouteData="routeData" DefaultLayout="typeof(Layout.MainLayout)" />
        <FocusOnNavigate RouteData="routeData" Selector="h1" />
    </Found>
</Router>

[guardrex]

@danroth27, we discussed the delta that removing those @ will create with the docs. If you go without them in the project template, shouldn't I make the doc set match? I'd kind'a prefer to do it because readers will spot it and open issues (and even patch PRs) for what they think are doc bugs.

[guardrex]

@halter73 ... In addition to any template change, I've opened a doc issue to improve additional assemblies coverage at ...

• Render modes doc: Discover components from additional assemblies for Static Server rendering section
• Fundamentals > Routing doc: Route to components from multiple assemblies section

BTW, I don't think that section title is accurate ...

Discover components from additional assemblies for Static Server rendering

Shouldn't that just state ...

Discover components from additional assemblies

[danroth27]

@danroth27, we discussed the delta that removing those @ will create with the docs. If you go without them in the project template, shouldn't I make the doc set match? I'd kind'a prefer to do it because readers will spot it and open issues (and even patch PRs) for what they think are doc bugs.

@guardrex Yeah, we're trying to standardize on a consistent style here. The style we're going with is to only include the @ if it's needed.

[ghost]

Hi @halter73. 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.

[guardrex]

@halter73 @javiercn ... Passing note and ❓ before we go here.

These definitions are similar WRT locating components ...

AdditionalAssemblies param on the Blazor router instance ...

Gets or sets a collection of additional assemblies that should be searched for components that can match URIs.

AddAdditionalAssemblies method for the endpoint convention builder ...

Summary ...

Adds the given additional assemblies to the component application.

Remark ...

The provided assemblies will be scanned for pages that will be mapped as endpoints.

Two questions ...

1. The API remark for the AddAdditionalAssemblies method makes it sound like one wouldn't need to specify the AdditionalAssemblies param on the router in order to discover routable client-side components. I tried removing the param from the router, leaving just the call to AddAdditionalAssemblies, and it worked. What should we say about this? Should we just say in a BWA that an assembly should be indicated in both spots anyway? ... which is what the project template sets up by default.

2. In the same vein as question 2, should component libraries also have their assemblies indicated to the AdditionalAssemblies parameter if the dev indicates the library's assembly to the AddAdditionalAssemblies method?

UPDATE: I placed a PR with draft improved language at dotnet/AspNetCore.Docs#31131.

[danroth27]

@guardrex I believe you need to specify AdditionalAssemblies on the Router to discover components in other assemblies when the Router is set up to be interactive, either from the server or the client. If the Router doesn't have an interactive render mode, then AddAdditionalAssemblies on MapRazorComponents should be sufficient.

[guardrex]

@danroth27 ... Thanks. I understand. I'll make further updates shortly and ping for review on the PR.

[guardrex]

Mmmmmmmm 🤔 ... Idk ... that doesn't sound like it matches the behavior.

HOLD for a sec. I need to research further. I lost a test app. I'll post back in a bit.

[guardrex]

Ok ... I think I get it now. I'll make the updates the PR and ping for review.

[ghost]

Hi @halter73. 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.