Blazor WebAssembly: Bidirektionale Kommunikation und Benachrichtigungen

Seite 4: Deployment

Inhaltsverzeichnis

Zum Abschluss dieses Tutorials soll es noch um die Verbreitung der Blazor-WebAssembly-Anwendung gehen. Die einfachste Möglichkeit zur Installation ist das direkte Veröffentlichen aus Visual Studio heraus über die Funktion Publish im Kontextmenü eines Webprojekts oder im Menü Build | Publish.

Im dann folgenden Dialog kann man zwischen verschiedenen Veröffentlichungszielen wählen (s. auch Abb. 6):

  • App Service: Verbreitung auf einen Windows-basierten App Service in der Azure-Cloud
  • App Service Linux: Verbreitung auf einen Linux-basierten App Service in der Azure-Cloud
  • Azure VM: Verbreitung auf eine virtuelle Maschine in der Azure-Cloud
  • Docker Container Registry: Verbreitung als Docker-Container auf Docker Hub oder die Azure Container Registry (ACR)
  • IIS, FTP: Veröffentlichung per FTP oder das IIS-Web-Deployment-Verfahren (alias MSDeploy)
  • Folder: Veröffentlichung in einen Dateisystemordner im lokalen Netzwerk

Konfiguration des Veröffentlichungsziels (Abb. 6)

Ergebnis dieses Assistenten ist ein sogenanntes Publishing Profile in Form einer XML-Datei mit der Dateinamenserweiterung .pubxml, die in dem Projekt im Ordner /Properties/PublishProfiles landet. Es kann beliebig viele Profile in einem Visual-Studio-Projekt geben, und ein gespeichertes Profil können Softwareentwickler später jederzeit wieder aufrufen.

Bei der Veröffentlichung nach Azure können Entwickler wahlweise auf einen bestehenden Azure App Service veröffentlichen oder auf einen neuen Azure App Service, den sie aus dem Visual-Studio-Veröffentlichungsassistenten heraus erst anlegen. Eine Blazor-WebAssembly-Anwendung lässt sich derzeit nur in einem Windows-basierten Azure App Service verwenden ("A Linux server image to host the app isn't available at this time."). Nur Blazor Server kann auch in Linux-basierten App Services laufen. Bei Veröffentlichung auf eine virtuelle Maschine können Entwickler nur eine VM wählen, die sie zuvor im Azure Portal oder mit Azure-Kommandozeilenwerkzeugen angelegt haben.

Bei der Veröffentlichung auf einen eigenen IIS-Webserver ist zu beachten, dass für eine Blazor-WebAssembly-Anwendung das IIS-Zusatzmodul "URL Rewrite" auf dem Webserversystem manuell zu installieren ist. Das ASP.NET Core Runtime Hosting Bundle ist hier nicht auf dem Webserver notwendig; dieses braucht man nur für das WebAPI-Projekt oder ein Blazor-Server- oder Blazor-WebAssembly-Projekt, das als "ASP.NET hosted" angelegt wurde.

Die Verbreitung einer Blazor-WebAssembly-Anwendung unter Verwendung einer Pipeline in einem DevOps-Tool (wie Azure DevOps) im Sinne des professionellen Continous Deployment ist möglich, wird hier aber nicht behandelt, weil das ein eigenes umfangreiches Themengebiet ist.

Damit geht das fünfteilige Blazor WebAssembly-Tutorial von heise Developer zu Ende. Leser haben zahlreiche Aspekte von Blazor WebAssembly gelernt: Einbindung von WebAPI-Backends, Rendern von Daten, Eingabeformular, Interoperabilität mit JavaScript, Authentifizierung und Autorisierung, lokale Persistenz im Browser und das Nachladen von Modulen sowie bidirektionale Kommunikation und Benachrichtigungen. Das Endergebnis des Programmcodes für das Blazor-WebAssembly-basierte Webfrontend "MiracleList" findet sich auf GitHub.

Sicherlich ist das nicht alles, was Blazor kann und was Entwickler können müssen, um eine Single Page Web Application in der Praxis zu schreiben. Als weiterführende Literatur sei auf die offizielle Dokumentation und die beiden Bücher des Autors zu Blazor 3.1/3.2 sowie Blazor 5.0 verwiesen.

Dr. Holger Schwichtenberg

ist Chief Technology Expert bei der MAXIMAGO-Softwareentwicklung. Mit dem Expertenteam bei www.IT-Visions.de bietet er zudem Beratung und Schulungen im Umfeld von Microsoft-, Java- und Web-Techniken an. Er ist Autor zahlreicher Bücher, u.a. "ASP.NET Core Blazor: Moderne Single-Page-Web-Applications mit .NET, C# und Visual Studio".

(ane)