Blazor Desktop

Eintrag zuletzt aktualisiert am: 24.11.2022

Mit .NET 6.0 hatte Microsoft mit Blazor Desktop eine dritte Architektur in die Blazor-Familie eingeführt. Während bei Blazor Server der C#-Programmcode auf einem ASP.NET Core-fähigen Webserver und bei Blazor WebAssembly direkt in der WebAssembly Virtual Machine des Browsers läuft, ist bei Blazor Desktop der Host eine .NET-basierte Anwendung.

Die offiziell erste einsatzreife Version von Blazor Desktop ist erst am 23.5.2022 zusammen mit .NET MAUI erschienen. Vorher war Blazor Desktop aber schon gut einsetzbar. Es gab aber in der RTM-Version noch einen kleinen Breaking Change. Dabei wurde AddBlazorWebView() ersetzt durch AddWindowsFormsBlazorWebView() und AddWpfBlazorWebView().

Als Host bei Blazor Desktop sind möglich:

• Eine Windows Forms-Anwendung, die nur auf Windows (ab Windows 7) läuft
• Eine App mit Windows Presentation Foundation (WPF), die nur auf Windows (ab Windows 7) läuft

Bei Blazor Desktop läuft die Blazor-Anwendung dabei nicht in einem Webserver und auch nicht einer Webassembly-VM, sondern im gleichen .NET 6.0-Prozess und sogar im gleichen Thread wie die Desktop- bzw. Mobil-Anwendung. Es gibt also keine Prozesstrennung wie bei Electron und damit auch keine Notwendigkeit des expliziten Nachrichtenverkehrs. In Blazor Server übernimmt die Kommunikation zwischen dem .NET Code im Host und dem WebView-Steuerelement ein "Native Interop Channel", dessen Arbeit für die Entwickler völlig unsichtbar ist. Alle .NET-APIs können direkt aufgerufen werden. Bei Blazor Desktop kommt also weder ein WebAPI (wie bei Blazor WebAssembly) noch SignalR (wie bei Blazor Server) zum Einsatz. Wie bei Blazor Server hat der Programmcode in Blazor Desktop vollen Zugriff auf alle Ressourcen des Betriebssystems.

Blazor Desktop kann also auch Datenbankmanagementsysteme direkt ansprechen – sofern das Betriebssystem dies unterstützt. Das ist in Windows möglich, auf Android und iOS aber nicht, weil es dort die passenden Treiber nicht gibt. Auf Mobilbetriebssystemen kann man nur lokale Datenbanken (meist SQLite) ansprechen.

Bei Blazor Desktop ist also – abhängig vom Betriebssystem – eine 2-Tier-Anwendung ohne Application Server/Middleware möglich; Geschäftslogik und Datenzugriffsschicht können im Client-Prozess laufen. Eine 3-Tier-Anwendung mit Middleware, also dem Datenzugriff via Webservices auf einen Application Server, ist natürlich immer auch möglich.

Blazor Desktop verwendet das gleiche Komponentenkonzept (Razor Components mit oder ohne Code-Behind-Datei) wie Blazor WebAssembly und Blazor Server. Eine Umstellung einer Blazor-Anwendung auf Blazor Desktop ist also einfach, egal ob diese mit Blazor WebAssembly (3-Tier) oder Blazor Server (2- oder 3-Tier) realisiert wurde. Lediglich der Startcode und die Startseite sind leicht verschieden in den drei Blazor-Architekturen. Darüberhinausgehende technische Unterschiede werden durch Dependency Injection unterschiedlicher Dienste weitgehend wegabstrahiert, z.B. für die Navigation und die Interoperabilität mit JavaScript.

In Blazor Desktop übernimmt die von Microsoft bereitgestellte JavaScript-Bibliothek blazor.webview.js die Weitergabe der Browser-Interaktionen an die Razor Component in Blazor sowie die Aktualisierung des HTML-DOM im Browser. Eine Blazor Desktop-Anwendung kann beliebig viele native Fenster umfassen, in die Blazor-Anwendungen via WebView eingebettet sind.

Bei der Programmiersprachenauswahl in Blazor Desktop ist der Entwickler auf C# reduziert, auch wenn WPF und Windows Forms ansonsten zusätzlich mit Visual Basic .NET möglich wären. Allerdings gibt es von Microsoft-Seite Blazor nur mit C#. Das Projekt "Bolero" [https://fsbolero.io] bietet zwar auch F# mit Blazor WebAssembly an, allerdings nur im Browser.

Sind die Inhalte hilfreich?