I have project that i want to build web app and mobile app using NET CORE
after research i just want to confirm the architecture=>> Blazor client side + asp core server side + NET MAUI for mobile.
i can build with these three projects in the same solution an apllication interact such as reading and writing information from and to the Mobile and web app
My question i can use Blazor WebAssembly for client-side web applications and ASP.NET Core for handling database interactions, APIs, and server-side processing. And, i can also use .NET MAUI for building mobile app all within the same solution.
We have old VB6 application, which must be upgraded to newer technology. The application is related to buyer's evaluation and should be transferred to website.
The language which we will use - is VB.NET (no way to be other) on .Net Core but I do not know which technology is better : Blazor WebAssembly, MVC or .NET MAUI
I found out free VS2022 projects for download - in Net7 on VB.NET and C# for Blazor WebAssembly and MVC at
VBlazor
The projects are free and included everything needed for our business needs - quick setup, CRUD, responsive web design, SEO, etc. But my problem is that there has not .NET MAUI solution.
So, my question is - do you think that .NET MAUI will be used in the future? And should we take care about it? Or just to use any of the other technologies.
And the other question - do you know somewhere VS2022 .NET MAUI projects for download, made in VB.NET?
Thanks
I have tried the VBlazor VB.NET project templates in Blazor WebAssembly and MVC, and they are working fine for us. But I am expecting to find project for .NET MAUI in VB.NET. Thanks
I have been working on authentication methods for my blazor app for some time now. I am currently developing as a standalone protected WebApi + Blazor Server, but will ultimately migrate to standalone protected WebApi + Hosted Blazor WASM so I need to be mindful of both server and client side authentication. The WebAPI will also serve an external OData feed and API for end users that also needs to be protected using the central authentication mechanism.
I would like to be able to sign on with Microsoft (ie. Microsoft.Identity.Web / MSAL), but want to configure some fairly complex roles and behaviours at the database level
(ie. ASP.NET Core Identity). To hopefully help someone else understand the different documentation sets, following are links to MS docs for the 2 options.
Introduction to Identity on ASP.NET Core
Microsoft Identity Platform Documentation
Don’t know about anyone else, but I have found it very difficult to navigate through the different documentation sets and tutorials to firstly understand how they work and secondly determine if it is best for me.
My question is, does anyone have any documentation on how they have integrated Microsoft.Identity.Web with the individual user accounts available in ASP.NET Core Identity for Blazor Server and/or WASM apps?, .
The following link shows how to do it all within ASP.NET Core Identity.
Integrate ASP.NET Core Identity with Microsoft account | BinaryIntellect Knowledge Base
If I was building an MVC web app, that’s what I would do. However, I really like the token handling capabilities of Microsoft.Identity.Web / MSAL (ie. ITokenAquisition etc.) for Blazor. It seems to be a real kludge to have to use the Razor pages for ASP.NET Core Identity and handling tokens securely becomes an issue – especially for Blazor WASM.
Chris Sainty has done some good work in porting some of the ASP.Net Razor pages to Blazor Components in the following link. However he does a lot of (very clever) manual processing of the token and I’m not sure I like the idea of storing the token in unprotected Local Storage of the blazor app. I haven’t gone into it in full detail yet, but I don’t think this method will be directly transferrable to Blazor WASM.
Authentication with client-side Blazor using WebAPI and ASP.NET Core Identity (chrissainty.com)
This SO post indicates that it is not possible to integrate Individual user accounts with Microsoft.Identity.Web.
c# - Microsoft Identity Plataform with asp.net Core Identity - Stack Overflow
I got a working solution going where I had both ASP.NET Core Identity and Microsoft.Identity.Web working side by side. However, I found this to be very difficult to implement and debug. Once you start mixing the various builder.Services.AddAuthetication(
) options (eg. .AddMicrosoftIdentityWebApp, . AddMicrosoftIdentityWebApi, .AddIdentityCore, .AddIdentity, .AddDefaultIdentity, .AddJWTBearer etc. etc.) I have found that you enter a world of pain and unpredictable behaviour. I basically had to go back to the source for each of them to work out what they were actually doing under the covers and work out how to blend them. I ended up going back to the raw OAuth / OpenId specifications and implementing everything manually – which is very unsatisfactory and I was unhappy with the risk I was taking in potentially introducing a security flaw – even though I got it to “work”.
EDIT: This SO post is similar to what I implemented. Microsoft Identity Local User Accounts and MSAL
I can’t believe how hard it has been to just get to this level of understanding, and still not have a solid working concept that does what I want it to do that is supported by documented acceptable techniques and not just my kludge at implementing everything manually.
Right now it appears to me that if I want to use as much out of the box / documented functionality as possible, I suspect that I should use ASP.NET Core Identity and work out how to integrate the ASP.net razor pages into my Web Api, Blazor Server and and Blazor WASM apps. However, this appears to be a backward step since Microsoft.Identity.Web / MSAL seems to be so much better suited to Blazor and seems to be the direction that MS is going.
If anyone can point me to some current examples of how this can be done, I would be very thankful.
I think I have found at least a partial answer to my question. The key problem I faced was how to capture the callback event from Microsoft.Identity.Web so that I can persist / retrieve info to/from the database during the authentication event. I was hung up on the ASP.NET Core Identity method of doing that.
I found the following SO post that provides information on how to respond to the OnTokenValidated event using Microsoft.Identity.Web. Microsoft.Identity.Web: OnTokenValidated event not triggered
Having access to this event means that I will be able to implement what I need to do at the database level and move on.
I want to build 2 apps.
Private API in .NET that takes care of database access / processing of data.
Blazor WebAssembly app which will connect to this API securely, to search data.
Since Blazor WebAssembly DLLs can be decompiled, I can't use any private/secret keys in the APP.
I don't want anyone being able to use the API if they discover the endpoints. Only the Blazor APP can use the API (and any other app I might build in the future).
How should I approach this? Is it even possible to do it securely or should I go Server Side?
Secure ASP.NET Core Blazor WebAssembly explains how to secure a Blazor WASM app
Blazor WebAssembly 3.2.0 Preview 2 release now available explains how to use IAccessTokenProvider to get the access token to authentify your applicaton on API.
I'm confused whats different between Razor components and Blazor and which is better and in the last release .NET Core 3.0 Preview 3 the add those to Razor Components
Razor Components improvements:
Single project template
New .razor extension
Endpoint routing integration
Prerendering
Razor Components in Razor Class Libraries
Improved event handling
Forms & validation
Essentially there are 3 parts to understand.
Razor Components
This is the name for the core, out of process, component model which was created back in July 2018, for the first release of Server-side Blazor.
Razor Components is the core of the framework and contains all the following things.
Parameters
Event handling
Data binding
Routing
Dependency injection
Layouts
Templating
Cascading values
Server-side Blazor
This is the server-side hosting model, running on ASP.NET Core, for Razor Components. This version hosts the Razor Components model on the server. It uses a small runtime to send UI events from the browser to the server. Once processed by Razor Components, any UI updates get sent back from the server to the browser and the runtime handles updating the DOM. All this communication is handled via a SignalR connection. Even JS interop calls are handled this way.
Client-side Blazor
This is the client-side hosting model for Razor Components.
In this model, everything is hosted in the browser. Mono, compiled to WebAssembly, is the .NET runtime. On top of this sits Razor Components and then finally the application.
The great thing about this architecture is that any feature added to Razor Components should, in theory, be available to both hosting models. Although in reality, this is not always the case.
What's better?
That very much depends on what you want to do.
Client-side Blazors biggest drawback is its download size. This alone could rule it out for many developers. Downloads are easily into multiple MBs which if someone is trying to view your app on a mobile with a slow connection, they are not going to have a great experience. However, it's worth noting that after the first download a lot of the content is cached so subsequent loads can be a few 100kb.
Client-side Blazors debugging experience is very primitive right now as well. Which means working on it as a developer can be challenging at times.
Server-side Blazor has a much nicer developer experience in terms of debugging. The app is much faster to download and only has a size of a few 100kb before any caching takes place.
The downside is potentially scalability. But this will very much depend on the number of concurrent users you are expecting. Because this model uses SignalR your app will have a top limit on concurrent connections. But, you can manage this by plugging into Azure SignalR to allow a far greater number of connections to your app.
Ultimately, both hosting models of Razor Components have a long way to go. The authentication stories for both are in very early days, although client-side Blazor is arguably in a better place. The routing engine is still limited, forms and validation have only just had it's first release and there is still work to do.
Another thing to keep in mind is that it is possible to swap between the models pretty easily. So whatever decision you make you're not tied into it. There will even be a way of doing this built into the framework at some point so nothing you do now will be wasted.
Any questions, please ask. But I hope this helps.
Razor Components is a framework with which you can create SPA web applications. It is divided into two mode of execution. When the web app is hosted and executed on the browser, it is called Blazor. Blazor applications are written in C# and compiled into .NET assemblies. They are executed and run on the browser as .NET assemblies by the Mono run time, which itself is compiled to Web Assembly.
The second mode of execution is server-side. That is, your web app is executed on the server, not on the browser. Note that here the runtime environment is not Mono Web Assembly but the Asp.net Core run time. This is called server-side Blazor, but the term Razor Components is used as well, so that the confused get perplexed. The reason for this is historic: At the beginning, there was only Blazor running on the browser. But then came the idea that a web app can run on the server, and only the diffs can be send to the browser by means of SignalR. Running the web app on the server is much easier than running on the browser, and the developer can use many elements he can't use on the browser, such as debugging, etc. As a result of this possibility, the Asp.Net renamed the Blazor framework as Razor Components, which you can treat as a super structure on which Blazor is built. This is why the confusion. Let's emphasize this division as follows:
Razor Components --> Blazor (front end; browser)
Razor Components --> Razor Components (server-side Blazor )
I know this is a source of confusion, but this is it...
As to the question which is better, I may only say that it depends exclusively on your requirements. Each of these mode of executions has its benefits and drawbacks. Blazor applications are more suitable for running on the internet as public web sites, whereas server-side Blazor application are best used on the Intranet as enterprise web sites.
The list you displayed is related to Razor Components framework. Some improvements, for the time being, may only be relevant to Blazor, others to server-side Blazor. There is only one way to know which is which: To learn Razor Components. It takes time to learn it, less than Angular, especially if you are a .Net developer, but it is still something which requires some investment.
Hope this helps...
I'll improve on it later on, but if you have specific question don't hesitate to ask...
You have every right to be confused, the naming has changed a lot and when you wrote the original question the Blazor team had recently renamed 'Server Side Blazor' as 'Razor Components'. That has thankfully since been abandoned, see the timeline below for more on that.
To anyone finding that the naming conventions in the answers here don't seem to marry up with what they are reading in older blog posts it's worth knowing that the meaning of 'Razor Components' has changed repeatedly over time.
This may also help anyone like me who has been using Blazor since near the beginning and feels sure that the names have changed!
TL; DR
The naming has evolved a lot during the pre-release period. Kudos to the Microsoft and the Blazor team for trying to come up with clear names and being willing to change back when needed. However, this has left a legacy of mixed naming conventions in older articles and some Blazor veterans sometimes use older naming conventions.
At the time of writing in September 2020, with Blazor at version 3.2, the official naming convention is:
Blazor Components (formally called 'Razor Components') can be used in...
Blazor Server apps, or ..
Blazor WebAssembly apps
The exciting history of Blazor naming
October 2018: 'Razor Components' becomes the new name for 'Blazor Server Side'
When Blazor 0.6.0 was released it was decided to officially name server side Blazor as 'Razor Components'.
Dan Roth discusses that in his Blazor 0.6.0 experimental release now available blog post in October 2018:
We announced last month at .NET Conf that we've decided to move
forward with shipping the Blazor server-side model as part of ASP.NET
Core in .NET Core 3.0. About half of Blazor users have indicated they
would use the Blazor server-side model, and shipping it in .NET Core
3.0 will make it available for production use. As part of integrating the Blazor component model into the ASP.NET Core we've decided to give
it a new name to differentiate it from the ability to run .NET in the
browser: Razor Components.
It's also discussed more in the ASP.NET Core updates in .NET Core 3.0 Preview 2 blog post.
Feb 19: Naming is hard...
Probably due to confusion that was arising, the Razor Components name for Server Side Blazor was expanded to 'ASP.NET Core Razor Components'. This is mentioned in the Blazor 0.8.0 release notes:
Server-side Blazor is now ASP.NET Core Razor Components in .NET Core
3.0 As was recently announced, server-side Blazor is now shipping as ASP.NET Core Razor Components in .NET Core 3.0. We've integrated the
Blazor component model into ASP.NET Core 3.0 and renamed it to Razor
Components. Blazor 0.8.0 is now built on Razor Components and enables
you to host Razor Components in the browser on WebAssembly.
April 2019: Switching back to Server-side Blazor
In April 2019 Blazor server side went into official preview and as part of that the naming for server side Blazor was switched back:
Simplifying the naming and versioning
For a while, we’ve used the terminology Razor Components in some cases, and Blazor in other
cases. This has proven to be confusing, so following a lot of
community feedback, we’ve decided to drop the name ASP.NET Core Razor
Components, and return to the name Server-side Blazor instead.
This emphasizes that Blazor is a single client app model with multiple
hosting models:
Server-side Blazor runs on the server via SignalR
Client-side Blazor runs client-side on WebAssembly
… but either way, it’s the same programming model. The same Blazor
components can be hosted in both environments.
Note that in the above description there is no mention of Razor Components at all, now we have two different Blazor hosting models (Client-side and server-side) as ways of delivering Blazor Components to the browser.
Sept 2019 The return of 'Razor Components'
Dan Roth's Blazor and .NET Core release notes for the next few versions no longer mention the term 'Razor Components' at all until .NET Core 3.0 Preview 9 when the term emerges again in the name of the 'Razor component unit test framework prototype'.
May 2020 'Razor Components' = 'Blazor Components'. Introducing 'Blazor Server' and 'Blazor WebAssembly'
By the time we get to May 2020 Razor Components and Blazor Components are now being used as synonyms for each other and the naming for the two hosting models has evolved.
The Blazor WebAssembly 3.2.0 now available blog describes that as follows (my emphasis):
Blazor components can then be hosted in different ways to create your web app. The first supported way is called Blazor Server. In
a Blazor Server app, the components run on the server using .NET Core.
And...
Blazor WebAssembly is now the second supported way to host your Blazor components: client-side in the browser using a WebAssembly-based .NET
runtime.
So.. the term 'Razor Components' is officially dead, right?
It would be so much easier if it was.. it does seem like 'Blazor Component' would be a more natural fit. But no, from the Components section of the official documentation:
Components in Blazor are formally referred to as Razor components.