What's the difference between ASP.NET Core Hosted and Server-Side Blazor, really?

Question

I'm still struggling to understand the difference between ASP.NET Core Hosted and Server-side Blazor. I know same question already exists, but it's not satisfying. In fact, I couldn't find the satisfying answer anywhere - the answers were more or less the same.

If hosted option uses server (IIS, Kestrel), then why server-side? Confusing... It's a shame that official documentation didn't shed the light either...

UPDATE

The confusion stems from the fact that we have THREE options to create Blazor application. After executing dotnew new --list I get:

dotnet new blazorserver (Blazor Server App)
dotnet blazorwasm (Blazor WebAssembly App)

However, there's a third option:

dotnet blazorwasm --hosted (or dotnet blazor --hosted)

It's the same as check box in Visual Studio when creating application:

The documentation says:

you have the option of configuring the app to use an ASP.NET Core backend by selecting the ASP.NET Core hosted check box

But no explanation was provided what does it mean...

Run on WebAssembly or the server Blazor can run your client-side C# code directly in the browser, using WebAssembly. Because it's real .NET running on WebAssembly, you can re-use code and libraries from server-side parts of your application. Alternatively, Blazor can run your client logic on the server. Client UI events are sent back to the server using SignalR - a real-time messaging framework. Once execution completes, the required UI changes are sent to the client and merged into the DOM — Jazb, Sep 25 '19 at 07:38
Possible duplicate of [Blazor, ASP.NET Core Hosted vs Server Side in ASP.NET Core](https://stackoverflow.com/questions/53332097/blazor-asp-net-core-hosted-vs-server-side-in-asp-net-core) — samjudson, Sep 25 '19 at 07:39
@samjudson If you paid attention, I have pointed to that question, but there's really no answer - that's why I'm asking again. — JohnyL, Sep 25 '19 at 07:46
@JohnB The question is: if both options use server, why two options? — JohnyL, Sep 25 '19 at 07:48
look at it from the perspective of `where` the html gets created if that helps? — Jazb, Sep 25 '19 at 07:50
but i agree - the naming is bloody confusing and just when you get used to something, they go and change it! :-) — Jazb, Sep 25 '19 at 08:03
Sometimes I think, Is 'Blazor' a 'old wine in a new bottle'? Because it looks like related to SilverLight, the technology that is failed to appeal the mass market due to HTML5/CSS3 and JS based frameworks. — Thangadurai, Sep 25 '19 at 08:11
@JohnB You're right))) But actually we have three options: blazorwasm, blazor hosted and blazor server-side! That is really confusing! :) — JohnyL, Sep 25 '19 at 08:21
Related : [Understanding Blazor Assembly with ASP.net Core Hosted Model](https://stackoverflow.com/q/62202022/60761) — Henk Holterman, Apr 28 '21 at 06:07

tomRedox · Answer 1 · 2020-09-10T13:26:23.457

56

Re this part of your question:

However, there's a third option:

dotnet blazorwasm --hosted (or dotnet blazor --hosted)

It's the same as check box in Visual Studio when creating application:

The documentation says:

you have the option of configuring the app to use an ASP.NET Core backend by selecting the ASP.NET Core hosted check box

But no explanation was provided what does it mean...

TL;DR

'Hosted' is used where you want the back-end of your site and the Blazor client using that back-end to both be hosted on the same website.

In Detail

I agree, the documentation really isn't terribly clear about all of this, but the explanation is actually simpler than it seems:

The Blazor app has to be 'hosted' somewhere

The first thing to remember is that the Blazor WebAssembly 'app' is not a standalone website, it's an app that's embedded in a website. In a lot of cases it will behave like a website, because it will be used as a Single Page Application, but that is by no means required.

Essentially the Blazor WebAssembly app is a series of files and a JavaScript file that are created by compiling/publishing your Blazor project.

Those files then need to be put on a website somewhere and the combination of the name of a div tag and the Blazor JS file produced for your site deals with wiring your app files into the WebAssembly part of the browser so that it's then rendered on the page.

The key here is that the website 'hosting' your Blazor app does not have to be an ASP.NET Core site. It could be any site, pure HTML, Drupal, whatever, it just needs to be shown on a browser that handles WebAssembly and JavaScript correctly.

However, if you're also writing the backend of your site in ASP.NET Core, you can reuse that site

So, your Blazor project doesn't have to be hosted in a website written in ASP.NET Core, but it does have to be hosted somewhere (so the user can see it).

If you're also writing the back-end of the site at the same time, e.g. if you're writing an API or SignalR hub to send and receive data from your Blazor client, and if you're writing that back-end in ASP.NET Core, then you can reuse that same site to also host your Blazor client.

This scenario is what the 'Hosted' option is for.

If you create a project using the template in the screenshot above, with the 'hosted' option ticked, you'll see that the [YourProjectName].Server project that's created is the Start Up project, but the index.html page that's shown when you run that project has come from the [YourProjectName].Client project.

This approach means you only have one site running on your server (which could be good or bad) and also means you won't run across any CORS issues.

But you don't have to have an ASP.NET Core site at all

If your Blazor site is a standalone site that doesn't read/write from any server, or if it only talks to 3rd party APIs or an existing Web API running on the older .NET Framework, then you don't actually need an ASP.NET Core site at all.

In that case you don't use the 'hosted' option.

Instead, you can simply publish your Blazor project and then take the files from the release folder and host them in any site.

edited Sep 10 '20 at 13:26

answered Sep 10 '20 at 13:07

tomRedox

18,963
13
90
126

Best answer of the lot. Do you know why the .Server project includes cshtml files and other bits that seem like they are pages? I thought cshtml files was the old name of razor pages? Why not calling them .razor? And how come they are still included on the server side? It seems to me the server side should have no pages and just API methods? – sw1337 Sep 14 '20 at 18:32
5

@BlazingNoob the cshtml pages actually **are** Razor pages, not Blazor components. If you look at the Startup.cs 'Configure' method you'll see the server app is configured to use both Razor pages and Blazor. Blazor and Razor are sharing the routing for the site, and so when you navigate to root of the site you'll end up on a Blazor page. However, if something causes an error before you get there you'll get taken to Error.cshtml (which is the 'outer' 'container' **'Host'** site's error page). The _Layout.chstml page is the shared layout page that's just being used by the Error page. – tomRedox Sep 14 '20 at 18:57
I'm slowly getting a sense of things. Note that I've never done MVC. From what I understand, historically in MVC apps, .cshtml is the extension for pages written in the Razor syntax (blend of html and C#). When Blazor was launched, they kept this for pages, but introduced .razor for components only. Then decided all pages and components should be suffixed with .razor. But when creating a hosted Blazor Webassembly project, the server part is actually an MVC web app, which has retained the cshtml suffix for its only page: the error page. Did I get this right? Most confusing for me at first. – sw1337 Sep 14 '20 at 19:42
2

@BlazingNoob, that's exactly right. Just to confuse things further, on the MVC side there are actually two types of server-served pages that use the .cshtml suffix: MVC pages and Razor Pages. Razor Pages are a lighter weight version of an MVC page that don't require a standalone controller to serve them. That's why there's no controller endpoint serving up the Error page. That then got very confusing when they decided to call Blazor components 'Razor Components' rather than 'Blazor components'. I'm still hoping they will change their mind on that. – tomRedox Sep 15 '20 at 08:46
@tomRedox Thanks so much for your answer! I have one more clarification to ask about since it is not clearly mentioned anywhere in Microsoft's docs. Does the Blazor WASM hosted backend ("Project.Server") actually use a Blazor Server (Uses SignalR by default) or a typical .NET Core Web API project? I'm guessing the latter because I don't see any Blazor Server middleware or websocket connections being established on the frontend, but this isn't explicitly (Or clearly implicitly) stated in the docs. Thanks again for taking the time to write your original answer. – Clark Brent Oct 04 '20 at 20:48
1

@clarkbrent it's a Web API project. There's a separate command for adding Blazor server side to am MVC site – tomRedox Oct 04 '20 at 20:55
@tomRedox I had a feeling. I think what really muddied up my understanding is that the Blazor WASM hosted backend project is named identical to what a typical Blazor Server project would be instead of a typical Web API project name. Thanks again! – Clark Brent Oct 04 '20 at 21:10
@tomRedox, this should be accepted answer. Thanks for the explanation, now it's clear for me. – Dennis Dec 31 '20 at 06:57
@tomRedox thanks first of all for the clear explanation! I understood that in the WASM hosted backend we create both a Client and a Server. The 2 of these do not communicate with SignalR but normal HTTP calls since the backend is a simple .NET Core Web Api. Question: did I understand well that in this scenario, even though we have a backend, the computation still happens on the frontend side like in the simple WASM scenario (non dotnet core hosted)? Thank you! – Tarta Mar 29 '21 at 10:35
@Tarta in Blazor WebAssembly the whole Blazor app is a self-contained entity that runs solely on the client. It may use a REST API, GraphQL, SignalR etc. to talk to some other service, but that's not required. When you use the Hosted option the server is simply providing a website to host the Blazor WebAssembly app, there's no code related to the actual operation of the Blazor app on the server. You could then have a REST API (or whatever) on that Server site too, but you'd only do that if your Blazor app needed data from the server. – tomRedox Mar 29 '21 at 10:41
@tomRedox clear! thank you! I wanted to double check because we are talking about client and server here. If our Blazor App was still relying on the server for all the computation then it would be exactly the same as the Blazor Server model. Instead, as you just confirmed, it's a full WASM entity, plus there is a backend in case needed. Thanks again! – Tarta Mar 29 '21 at 10:48
1

@Tarta re this bit "If our Blazor App was still relying on the server for all the computation then it would be exactly the same as the Blazor Server model". That's not quite right, in Blazor Server the code runs on the server, so you don't need a rest API, you can talk straight to EF for example (which won't work in Blazor WASM). Blazor Server is more like a WinForms app in that regard. Blazor Server is effectively behaving like a TS/RDP session where user inputs are passed to the server, then all the work is done on the server and then the changes to the UI are passed back to the client – tomRedox Mar 29 '21 at 11:35
@tomRedox thanks again for the explanation! If I may ask you another question.. this sentence set me off: "or if it only talks to 3rd party APIs", related to the fact that if our WASM app just needs to talk to 3rd party APIs then we don't need to make it being hosted by .net core. The thing is that WASM doesn't make any HTTP calls by itself, the browser does. And all browsers are built to refuse to connect to any endpoint not specified through a CORS policy. Does your sentence still stand? Not an accusation of any kind of course :) I just need to understand haha – Tarta Mar 29 '21 at 17:45
1

@Tarta I haven't had the fun of CORS with Blazor yet, so honestly I don't know. All our stuff to date has been calling our own APIs. I assume there must be a way to do that, it's a pretty standard use case. – tomRedox Mar 29 '21 at 18:00

Ghasan غسان · Accepted Answer · 2021-05-18T01:27:25.257

Update

I see where you are coming from now. The confusion stems from the fact that you have an option called --hosted when using the client-hosted Blazor. This options means having Blazor to include ASP.NET Core runtime.

Why this option? Because you can write an offline app (e.g. calculator app) that does not need any kind of connection to external services, making ASP.NET Core irrelevant. However, you might want to write an online app that accesses online DB, external APIs, do verification, etc. For these kind of apps, you will need an ASP.NET Core stack to support your app.

Check this FAQ: https://github.com/aspnet/Blazor/wiki/FAQ#q-can-i-use-blazor-with-aspnet-core-on-the-server

Original answer

They are two hosting models: server-hosted, and client-hosted.

The difference is whether the app is hosted in server, or in client. Server hosting means your app logic runs in the server (you can think of it similar to what Web Forms is), you click on a button, an "Ajax" call sends the request, the server receives the request, and sends back the updated page. However, here it uses SignalR not Ajax, which is a low level socket communication (read efficient). And instead of updating a whole page, it updates only the relevant parts (thus it is a single page application).

On the other hand, client hosting means your logic runs within the browser. Think of it as if your C# logic is converted into JS, and it is embedded in the page. So the logic runs in the browser. This is possible after the introduction of WebAssembly which you might want to read about.

Let's say you want to create a calculator app. Your server hosted app will then need to communicate with the server to calculate and get the result for each calculation, while the client hosted does not need, and calculates the result in browser.

You might wonder, why we have two options. The reason being that support for WebAssembly (which a client hosted app relies on) is either incomplete or non-existant in many browsers, and performance differs widely too.

https://caniuse.com/#feat=wasm

So: 1) *blazor*: all the html rendering and app's logic are executed solely in browser; 2) *hosted*: browser is rendering only HTML, but all the logic is executed on the server (and interaction goes thru SignalR); 3) *server-side*: **???** — JohnyL, Sep 25 '19 at 08:20
@JohnyL There are only two versions: client-hosted (code runs in browser) or server-hosted (code runs in server). — Ghasan غسان, Sep 25 '19 at 08:38
Thanks for clarifying update! Now the puzzle has been solved! Thanks! — JohnyL, Sep 26 '19 at 20:13
Downvoted because the first part of the answer isn't relevant to the question, and the second part doesn't properly explain the difference in how the Blazor app is served to the browser when the `--hosted` option is used. — Craig Brown, Sep 15 '20 at 11:39

Habeeb · Answer 3 · 2021-02-18T06:27:52.917

The question is about the option "ASP.NET Core hosted" in Visual Studio, while creating a new Blazor Project with Blazor WebAssembly App.

Selecting this option scaffolds out 3 Projects for you (vs 1 WebAssembly project, if this option is not selected)

Server Side Blazor Project
Client Side Blazor Project (WebAssembly)
Shared project for shared entities between Server and Client Projects.

With this option you can have

Blazor WebAssembly only option for sections of your project where the logic can execute in browser.
Server hosted option where all the processing is done on server and only HTML is rendered onto the browser.

When deployed, all these projects go to the same location. So if you have a requirement for both Server Side as well as Client side options, then go for it.

Thanks for one more good answer! +1 for effort! – JohnyL Jan 23 '21 at 17:54 — JohnyL, Jan 23 '21 at 17:54

score 8 · Answer 4 · edited Jun 20 '20 at 09:12

I too had the same confusion while reading the documentation. But it was explained in Blazor webassembly section

dotnet blazorwasm - is a standalone project

dotnet blazorwasm --hosted (or dotnet blazor --hosted) - is a projected hosted with ASP.NET Core backing API's.

A hosted deployment serves the Blazor WebAssembly app to browsers from an ASP.NET Core app that runs on a web server.

The client Blazor WebAssembly app is published into the /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot folder of the server app, along with any other static web assets of the server app. The two apps are deployed together. A web server that is capable of hosting an ASP.NET Core app is required. For a hosted deployment, Visual Studio includes the Blazor WebAssembly App project template (blazorwasm template when using the dotnet new command) with the Hosted option selected (-ho|--hosted when using the dotnet new command).

score 0 · Answer 5 · answered Feb 03 '21 at 13:35

0

One big advatage of the blazor asp.net core hosted model is that one that you can use many great things from the server, but still they need to be called via API. Which is totally OK if you are not wiling to use blazor server side or blazor client side without e.g. Identity System.

answered Feb 03 '21 at 13:35

J S

57
5

1

This does not answer the question. – Connor Low Feb 03 '21 at 18:45

score -1 · Answer 6 · answered Apr 28 '21 at 03:16

-1

So Blazor server uses SignalR to communicate between server and client whereas Blazor WASM uses WASM(client-side, no communication after the first load) with backend asp.net core(if --hosted).

answered Apr 28 '21 at 03:16

Sunghoon Park

1