BWA project template: "@" on @render-mode values and .Client project assembly discovery

[guardrex]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Creating an app from the BWA project template with global WASM interactivity produces ...

<HeadOutlet @rendermode="@InteractiveWebAssembly" />
...
<Routes @rendermode="@InteractiveWebAssembly" />

Although the at-symbols (@) on the values are fine, it departs from our guidance to not place them on values of attribute directives outside of explicit Razor expressions [@(...)].

I recommend 🔪 them off; but if you plan to keep these, it creates a delta between the framework and docs, so how would you like to proceed? Let the delta stand, or change all of the docs to this format for directive attributes? If the latter, it will need to be pushed back quite a bit (24Q1/Q2) because it's a 🐘 job to change them everywhere and I'm 🏃‍♂️ on many high priority issues for quite a while.

I opened a docs issue just to call out that this is a supported approach if the dev wants to write their markup this way. dotnet/AspNetCore.Docs#31042

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.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response