Consider restoring the Blazor WebAssembly "hosted" option

[SteveSandersonMS]

We recently removed the --hosted option from the Blazor WebAssembly project template, on the grounds that we considered it unnecessary now that the new blazor template includes support for WebAssembly components on an ASP.NET Core host.

However, there are still clear use cases for dotnet new blazorwasm --hosted:

1. If you want a WebAssembly-everywhere project, like we offered in .NET 7 and earlier, it would be really hard to set that up without a template for it. You'd need to do dotnet new blazor --use-wasm, then make lots of changes to move files into the WebAssembly project.
   • Further, if auth is enabled, how would people even know if they've done it right?
2. If you want an ASP.NET-hosted PWA, this is likely going to be the only way it could work. I think we will not offer a --pwa option on the Blazor Web project, because it couldn't work offline by default (we can't cache all the SSR pages, we don't even have a way to discover them all). If our PWA is to continue meaning "offline-enabled PWA", then that will only be able to work in a WebAssembly-everywhere case, and so we need to use the blazorwasm template for that. If someone wants to combine this with being ASP.NET Core-hosted, they will need blazorwasm --hosted to be brought back.

[mkArtakMSFT]

We're going to bring back the hosted option with an additional log message suggesting that the new template should be preferred in case of it meets all the requirements the developer has.

[AlbertoPa]

Currently the new "Blazor Web App" template does not offer the option to configure a Web API that can be called from WebAssembly. What is the guidance for a WASM app based on the new template to interface, for example, to a database in simple scenarios where there is no clear need for a separate Web API app? It is a common scenario for a client-side app.

[mkArtakMSFT]

Closing this in favor of #50433

[revbones-dev]

Well this sucks. Closing this in favor of #50433 ignores all the reasons expressed above to have a hosted template. Doubling down on "interactive" components doesn't solve the issues this ticket was opened for.

[SteveSandersonMS]

I don't know your scenario exactly, but just to clarify, the approach we've taken doesn't ignore the points raised above. It accounts for scenario 1 (WebAssembly-everywhere projects) completely. It doesn't deal with scenario 2 (PWAs) so yes you would have to add the service-worker.js manually in that case.

[revbones-dev]

Steve - I sincerely appreciate your reply here. In your comment opening this issue you said "If you want a WebAssembly-everywhere project, like we offered in .NET 7 and earlier, it would be really hard to set that up without a template for it."

We do law enforcement applications and require offline capabilities because troopers/officers travel around and have spotty Internet service. In one case we've gone with .NET MAUI Blazor Hybrid for an installable client, but in several other cases we use Blazor WASM. I've been excited for Blazor as it's prevented us from having to go with React\Angular\Vue for SPA applications.

The hosted solution was perfect for creating a Blazor WebAssembly SPA, since it included the API, set everything up to work against it, had the shared project and we could build/deploy the API and SPA together. Maybe I'm not catching on yet, but it feels like WASM is being looked at now to just targeting a few "interactive" components in basically a Blazor Server app instead of it acting as a SPA on its own. I have teams for 17 states, and we have stayed away from Blazor Server due to the connectivity requirements in all but a small intranet criminal history application. WebAssembly in the hosted model was perfect for us (aside from it lacking in the auth dept). I have searched and been unable to find anything about things like:

1. How does the Blazor Web App template replace the API aspect of the Hosted template? Does this have to be manually created/added now?
2. How would a component know it's running in WebAssembly vs otherwise to manage api calls via an HttpClient vs if it's running on the server? I have seen commentary that an abstraction layer would need to be in place but nothing on what that would look like.

Also, since you might see this reply - hot reload is completely broken in Visual Studio 2022 Preview 17.8 Preview 2 for solutions created using the hosted template. Works fine for projects created using the new Blazor Web App template, just not for any of our solutions based on I opened up a ticket on the Visual Studio Dev Community Site with a sample project and reproduction steps.

[SteveSandersonMS]

You won't find any docs about this yet because they are only produced as part of the final 8.0 updates.

How does the Blazor Web App template replace the API aspect of the Hosted template? Does this have to be manually created/added now?

If you enable global interactivity, it's just like the "Blazor WebAssembly hosted in ASP.NET Core" option from 7.0 and earlier. So you add WebAPIs to your server project just like before.

How would a component know it's running in WebAssembly vs otherwise to manage api calls via an HttpClient vs if it's running on the server?

If you enable global interactivity with WebAssembly, all your components are running on WebAssembly just like before.

[guardrex]

enable global interactivity

DR and I just placed some coverage on this subject. Note that product unit engineers might not have seen it yet. We'll have a major docs review before RTM (I hope 🤞🍀😄).

https://learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-8.0#set-the-render-mode-for-the-entire-app

The Call web API guidance has been updated (i.e., language updates) for 8.0. The main scenarios are no different than what we had before ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/call-web-api?view=aspnetcore-8.0&pivots=webassembly

Migration guidance for hosted WASM via the WASM template of 7.0 to hosted WASM via the BWA template of 8.0 (including PWA) is forthcoming. There's still too much framework churn right now for me to write up migration guidance. I'll reach it after RC2 comes out in a few weeks.

[revbones-dev]

Is global interactivity supposed to work in RC1 for WebAssembly?

Setting is as follows, results in an error:

<Router AppAssembly="@typeof(App).Assembly" 
        AdditionalAssemblies="new[] { typeof(Client._Imports).Assembly }"
        @rendermode="@RenderMode.WebAssembly">
    <Found Context="routeData">
        <RouteView RouteData="@routeData" DefaultLayout="@typeof(Layout.MainLayout)" />
        <FocusOnNavigate RouteData="@routeData" Selector="h1" />
    </Found>
</Router>

The error is:
InvalidOperationException: Cannot pass RenderFragment parameter 'Found' to component 'Router' with rendermode 'WebAssemblyRenderMode'. Templated content can't be passed across a rendermode boundary, because it is arbitrary code and cannot be serialized.

This is in a new Blazor Web App project with the only change made being adding the rendermode as indicated in the code. I apologize if this is an error that should be reported elsewhere, it just seemed germane to the discussion here.

[guardrex]

@revbones-dev ... See ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-8.0#set-the-render-mode-for-the-entire-app

[revbones-dev]

Sorry - that seemed to be a response to a message I added and deleted after finding that link. I tried it and got the error I mentioned before your comment.

[guardrex]

@revbones-dev ... If it isn't working, please open a new issue with all of the details. The team doesn't work on closed issues/PRs.

[revbones-dev]

Will do - I just wasn't sure if I was on the right track. Seems like I was and it's just broken in RC1. I appreciate both your and Steve's responses.