Rumor has it, this is the dream of many .NET developers: Using SQLite and EF Core in the browser with Blazor WebAssembly. Is this possible? In this article, we will have a look how you can manage your offline data with the help of SQLite and EF Core by persisting the data with standard browser features and APIs.
Das Blazor Framework von Microsoft gibt es inzwischen in drei „Geschmacksrichtungen“. Die erste ist Blazor WebAssembly, die zweite Blazor Server, und zu guter Letzt gibt es noch Blazor Hybrid. In diesem Artikel wollen wir uns die zwei „echten“, also Browser-basierten, Web-Anwendungs-Szenarien WebAssembly und Server anschauen.
Im ersten Teil der Artikelserie haben wir uns angesehen, wie sich ein Blazor-WebAssembly-Client mit Hilfe eines Identity Providers (IDP) sicher mit einer Web API kommunizieren kann. Hierzu wurde IdentityServer als IDP genutzt. In diesem Teil widmen wir uns einem alternativen IDP, nämlich Keycloak. Wie auch im vorherigen Artikel, betrachten wir hier die Authentifizierung des Blazor-Clients und wie wir die Client-UI anhand von Autorisierungsinformationen anpassen können.
Dieser Artikel basiert auf den Inhalten des Webinars ‚Blazor WebAssembly: Neues in .NET 5‘ und soll eine kurze Zusammenfassung der wichtigsten Punkte liefern. Hier finden Sie alle Details, das Slidedeck, die zahlreichen technischen Demos, das Webinarvideo und der Source Code.
Ein bei Entwicklern vielleicht nicht immer so beliebtes, aber für den Endbenutzer enorm wichtiges Thema, ist das Abfangen und Behandeln von Fehlern.
Selbst wenn eine Anwendung vor der Bereitstellung gründlich getestet wurde ist es immer möglich, dass der Benutzer auf (unerwartete) Fehler stößt.
In diesem Artikel schauen wir uns anhand eines Beispiels an, wie wir Fehler in Blazor WebAssembly an zentraler Stelle abfangen und verarbeiten können.
In general, you can divide template engines into two types. The relatively simple ones are using template strings with placeholders to be replaced by some concrete values. The other template engines can do everything the simple ones can but additionally provide means for control of the code flow, like if-else statements, loops, and further. In this article, I will focus on the latter by using the Razor engine inside a Blazor WebAssembly application.
When people talk about WebAssembly and .NET Core these days, they immediately think about Blazor WebAssembly. But there is more to it. Actually, Blazor WebAssembly currently does not run our code as a WebAssembly (Wasm) module, but rather runs the .NET CLR (or a Mono version of it) as a Wasm module and our .NET code is run as plain old .NET assemblies on top of it. But there is indeed the need for executing (native) code as WebAssembly modules in the browser, and in .NET Core applications as well. In this article, I show how you can achieve running Wasm code in .NET Core, with a most likely future-proof approach.
With Blazor WebAssembly we are now able to create single-page applications (SPA) using C# and the ASP.NET Core Framework. When coming from ASP.NET Core MVC, you may ask yourself what .NET features are available, limited, or not available when running in the browser. One of them is logging, which is a basic means for debugging in both production environments and during development.
Microsoft’s Blazor WebAssembly toolkit is one of the new kids on the block in WebAssembly land. For many developers WebAssembly (or WASM) is the origin for a new revolution in the web. We can finally(?) use other languages and frameworks than JavaScript to run applications in a standards-based way in a cross-platform fashion on all browsers, on any devices (please refer to the current support of WebAssembly in your browser).
