Hosten und Bereitstellen von ASP.NET Core Blazor WebAssembly

In diesem Artikel wird erläutert, wie Sie eine Blazor WebAssembly-App mithilfe von ASP.NET Core, Content Delivery Networks (CDNs), Dateiservern und GitHub-Seiten hosten und bereitstellen.

Mit dem Blazor WebAssembly-Hostingmodell:

• Die Blazor-App, ihre Abhängigkeiten und die .NET-Runtime werden parallel im Browser heruntergeladen.
• Die App wird direkt im UI-Thread des Browsers ausgeführt.

Hosten von Unterdomänen und IIS-Unteranwendungen

Für das Unterdomänenhosting ist keine spezielle Konfiguration der App erforderlich. Sie müssen den App-Basispfad (das <base>-Tag in wwwroot/index.html) nicht konfigurieren, um die App in einer Unterdomäne zu hosten.

Für das IIS-Unteranwendungshosting müssen Sie den App-Basispfad festlegen. Weitere Informationen und Links zu weiteren Leitfäden zum IIS-Unteranwendungshosting finden Sie unter Hosten und Bereitstellen mit ASP.NET Core Blazor.

Verringern der maximalen Heapgröße für Browser auf einigen mobilen Geräten

<EmccMaximumHeapSize>268435456</EmccMaximumHeapSize>

Weitere Informationen zu Mono-/WebAssembly-MSBuild-Eigenschaften und -Zielen finden Sie unter WasmApp.Common.targets (im GitHub-Repository dotnet/runtime).

<PropertyGroup>
  <WasmEnableWebcil>false</WasmEnableWebcil>
</PropertyGroup>

Anpassen des Ladens von Startressourcen

Passen Sie an, wie Startressourcen mithilfe der loadBootResource-API geladen werden. Weitere Informationen finden Sie unter Starten von ASP.NET CoreBlazor.

Komprimierung

Wenn eine Blazor WebAssembly-App veröffentlicht wird, wird die Ausgabe bei der Veröffentlichung statisch komprimiert, um die App-Größe zu verringern und den Aufwand für eine Laufzeitkomprimierung zu beseitigen. Die folgenden Komprimierungsalgorithmen werden verwendet:

• Brotli (höchste Stufe)
• Gzip

• Informationen zur Komprimierungskonfiguration der Datei web.config von IIS finden Sie im Abschnitt IIS: Brotli- und Gzip-Komprimierung.
• Beim Hosten über statische Hostinglösungen, die die Inhaltsaushandlung für statisch komprimierte Dateien nicht unterstützen, sollten Sie die App so konfigurieren, dass sie die in das Brotli-Format komprimierten Dateien abruft und decodiert:

Rufen Sie den JavaScript Brotli-Decoder aus dem GitHub-Repository google/brotli ab. Die verkleinerte Decoderdatei heißt decode.min.js und befindet sich im Ordner js des Repositorys.

Aktualisieren Sie die App zur Verwendung des Decoders.

Legen Sie autostart in der wwwroot/index.htmlDatei im <script>-Tag von Blazor auf false fest:

<script src="_framework/blazor.webassembly.js" autostart="false"></script>

Fügen Sie nach dem <script>-Tag von Blazor und vor dem schließenden </body>-Tag den folgenden JavaScript-<script>-Codeblock hinzu.

<script type="module">
  import { BrotliDecode } from './decode.min.js';
  Blazor.start({
    webAssembly: {
      loadBootResource: function (type, name, defaultUri, integrity) {
        if (type !== 'dotnetjs' && location.hostname !== 'localhost' && type !== 'configuration' && type !== 'manifest') {
          return (async function () {
            const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
            if (!response.ok) {
              throw new Error(response.statusText);
            }
            const originalResponseBuffer = await response.arrayBuffer();
            const originalResponseArray = new Int8Array(originalResponseBuffer);
            const decompressedResponseArray = BrotliDecode(originalResponseArray);
            const contentType = type === 
              'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
            return new Response(decompressedResponseArray, 
              { headers: { 'content-type': contentType } });
          })();
        }
      }
    }
  });
</script>

<script type="module">
  import { BrotliDecode } from './decode.min.js';
  Blazor.start({
    loadBootResource: function (type, name, defaultUri, integrity) {
      if (type !== 'dotnetjs' && location.hostname !== 'localhost' && type !== 'configuration') {
        return (async function () {
          const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
          if (!response.ok) {
            throw new Error(response.statusText);
          }
          const originalResponseBuffer = await response.arrayBuffer();
          const originalResponseArray = new Int8Array(originalResponseBuffer);
          const decompressedResponseArray = BrotliDecode(originalResponseArray);
          const contentType = type === 
            'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
          return new Response(decompressedResponseArray, 
            { headers: { 'content-type': contentType } });
        })();
      }
    }
  });
</script>

Weitere Informationen zum Laden von Startressourcen finden Sie unter Starten von ASP.NET CoreBlazor.

<PropertyGroup>
  <CompressionEnabled>false</CompressionEnabled>
</PropertyGroup>

dotnet publish -p:CompressionEnabled=false

<PropertyGroup>
  <BlazorEnableCompression>false</BlazorEnableCompression>
</PropertyGroup>

dotnet publish -p:BlazorEnableCompression=false

Erneutes Generieren von URLs für ein ordnungsgemäßes Routing

Routinganforderungen für Seitenkomponenten in einer Blazor WebAssembly-App sind nicht so unkompliziert wie Routinganforderungen in einer Blazor Server-App. Betrachten wir eine Blazor WebAssembly-App mit zwei Komponenten:

• Main.razor: Wird im Stammverzeichnis der App geladen und enthält einen Link zur About-Komponente (href="About").
• About.razor: About-Komponente.

Wenn das Standarddokument der App über die Adressleiste des Browsers (z. B. https://www.contoso.com/) angefordert wird, geschieht Folgendes:

1. Der Browser sendet eine Anforderung.
2. Die Standardseite wird zurückgegeben, in der Regel index.html.
3. index.html startet die App.
4. Die Router-Komponente wird geladen, und die RazorMain-Komponente wird gerendert.

Auf der Seite „Main“ kann der Link zur About-Komponente auf dem Client ausgewählt werden, da der Blazor-Router dafür sorgt, dass der Browser im Internet keine Anforderung für About an www.contoso.com sendet, und stattdessen die gerenderte About-Komponente selbst bereitstellt. Alle Anforderungen von internen Endpunkten innerhalb der Blazor WebAssembly-App funktionieren auf dieselbe Weise: Durch Anforderungen werden keine browserbasierten Anforderungen an serverseitig gehostete Ressourcen im Internet ausgelöst. Der Router verarbeitet Anforderungen intern.

Wenn eine Anforderung für www.contoso.com/About über die Adressleiste des Browsers gesendet wird, tritt bei der Anforderung ein Fehler auf. Diese Ressource ist im Internethost der App nicht vorhanden. Daher wird die Antwort 404 Nicht gefunden zurückgegeben.

Da Browser Anforderungen für clientseitige Seiten an internetbasierte Hosts senden, müssen Webserver und Hostingdienste alle Anforderungen für Ressourcen, die sich nicht physisch auf dem Server befinden, auf der Seite index.html erneut generieren. Wenn index.html zurückgegeben wird, übernimmt der Blazor-Router der App und antwortet mit der richtigen Ressource.

Wenn Sie die Bereitstellung auf einem IIS-Server durchführen, können Sie das URL-Rewrite-Modul mit der veröffentlichten web.config-Datei der App verwenden. Weitere Informationen finden Sie im Abschnitt IIS.

<SelfContained>false</SelfContained>

<RuntimeIdentifier>{RID}</RuntimeIdentifier>

<SelfContained>false</SelfContained>

Eigenständige Bereitstellung

Bei einer eigenständigen Bereitstellung wird die Blazor WebAssembly-App in Form von statischen Dateien bereitgestellt, die von Clients direkt angefordert werden. Jeder Server für statische Dateien kann die Blazor-App bedienen.

Eigenständige Bereitstellungsressourcen werden entweder im Ordner /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot oder bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish\ (abhängig von der verwendeten Version des .NET SDK) veröffentlicht, wobei der {TARGET FRAMEWORK} Platzhalter das Zielframework ist.

Azure App Service

Blazor WebAssembly-Apps können in Azure App Service unter Windows bereitgestellt werden. Dort wird die App auf IIS gehostet.

Die Bereitstellung einer eigenständigen Blazor WebAssembly-App in Azure App Service für Linux wird derzeit nicht unterstützt. Wir empfehlen, eine eigenständige Blazor WebAssembly App mit Azure Static Web Apps zu hosten, was dieses Szenario unterstützt.

Azure Static Web Apps

Verwenden Sie einen der folgenden Ansätze, um eine Blazor WebAssembly-App in Azure Static Web Apps bereitzustellen:

• Bereitstellen aus Visual Studio
• Bereitstellen aus Visual Studio Code
• Bereitstellung aus GitHub

Bereitstellen aus Visual Studio

Erstellen Sie zum Bereitstellen über Visual Studio ein Veröffentlichungsprofil für Azure Static Web Apps:

1. Speichern Sie alle nicht gespeicherten Arbeiten im Projekt, da während des Prozesses möglicherweise ein Neustart von Visual Studio erforderlich ist.

2. Wählen Sie auf der Benutzeroberfläche Veröffentlichen in Visual Studio Ziel>Azure>Bestimmtes Ziel>Azure Static Web Apps aus, um ein Veröffentlichungsprofil zu erstellen.

3. Wenn die Azure WebJobs Tools-Komponente für Visual Studio nicht installiert ist, wird eine Aufforderung zum Installieren der ASP.NET- und Webentwicklungskomponente angezeigt. Befolgen Sie die Anweisungen, um die Tools mithilfe des Visual Studio-Installers zu installieren. Visual Studio wird während der Installation der Tools automatisch geschlossen und wieder geöffnet. Nachdem die Tools installiert wurden, beginnen Sie mit dem ersten Schritt, um das Veröffentlichungsprofil zu erstellen.

4. Geben Sie in der Konfiguration des Veröffentlichungsprofils den Namen des Abonnements an. Wählen Sie eine vorhandene Instanz aus, oder wählen Sie Neue Instanz erstellen aus. Legen Sie beim Erstellen einer neuen Instanz auf der Benutzeroberfläche Statische Web-App erstellen im Azure-Portal Bereitstellungsdetails>Quelle auf Andere fest. Warten Sie, bis die Bereitstellung im Azure-Portal abgeschlossen ist, bevor Sie fortfahren.

5. Wählen Sie in der Konfiguration des Veröffentlichungsprofils die Azure Static Web Apps-Instanz aus der Ressourcengruppe der Instanz aus. Wählen Sie Fertig stellen aus, um das Veröffentlichungsprofil zu erstellen. Wenn Visual Studio zur Installation der Static Web Apps CLI (SWA) auffordert, installieren Sie die CLI, indem Sie die Aufforderungen befolgen. Für die SWA CLI ist NPM/Node.js (Visual Studio-Dokumentation) erforderlich.

Nachdem das Veröffentlichungsprofil erstellt wurde, stellen Sie die App in der Azure Static Web Apps-Instanz mithilfe des Veröffentlichungsprofils bereit, indem Sie die Schaltfläche Veröffentlichen auswählen.

Bereitstellen aus Visual Studio Code

Informationen zum Bereitstellen aus Visual Studio Code finden Sie unter Schnellstart: Erstellen Ihrer ersten statischen Website mit Azure Static Web Apps.

Bereitstellen über GitHub

Informationen zum Bereitstellen über ein GitHub-Repository finden Sie unter Tutorial: Erstellen einer statischen Web-App mit Blazor in Azure Static Web Apps.

IIS

IIS ist ein leistungsfähiger Server für statische Dateien für Blazor-Apps. Informationen zum Konfigurieren von IIS zum Hosten von Blazor finden Sie unter Build a Static Website on IIS (Erstellen einer statischen Website unter IIS).

Veröffentlichte Ressourcen werden im Ordner /bin/Release/{TARGET FRAMEWORK}/publish oder bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish erstellt, je nachdem, welche Version des SDK verwendet wird und wo der Platzhalter {TARGET FRAMEWORK} das Zielframework ist. Die Inhalte des Ordners publish werden auf dem Webserver oder über den Hostingdienst gehostet.

web.config

Beim Veröffentlichen eines Blazor-Projekts wird eine web.config-Datei mit der folgenden IIS-Konfiguration erstellt:

• MIME-Typen
• Für die folgenden MIME-Typen wird die HTTP-Komprimierung aktiviert:
  • application/octet-stream
  • application/wasm
• URL-Rewrite-Modul-Regeln werden eingerichtet:
  • Stellen Sie das Unterverzeichnis bereit, in dem sich die statischen Objekte der App befinden (wwwroot/{PATH REQUESTED}).
  • Richten Sie ein SPA-Fallbackrouting ein, sodass Anforderungen für nicht dateibasierte Objekte an das Standarddokument der App im entsprechenden Ordner für statische Objekte (wwwroot/index.html) umgeleitet werden.

Verwenden einer benutzerdefinierten web.config-Datei

So verwenden Sie eine benutzerdefinierte web.config-Datei:

Wenn die Generierung oder Transformation von web.config durch das SDK während der Veröffentlichung entweder die Datei nicht in die veröffentlichten Ressourcen im Ordner publish verschiebt oder die benutzerdefinierte Konfiguration in Ihrer benutzerdefinierten Datei web.config ändert, greifen Sie je nach Bedarf auf einen der folgenden Ansätze zurück, um die volle Kontrolle über den Prozess zu übernehmen:

• Wenn das SDK die Datei nicht generiert, z. B. in einer eigenständigen Blazor WebAssembly-App in /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot oder bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish, je nachdem, welche Version des SDK verwendet wird und wo der Platzhalter {TARGET FRAMEWORK} das Zielframework angibt, legen Sie in der Projektdatei (.csproj) die Eigenschaft <PublishIISAssets> auf true fest. Für eigenständige WebAsssembly-Apps ist dies in der Regel die einzige erforderliche Einstellung, um eine benutzerdefinierte web.config-Datei zu verschieben und die Transformation der Datei durch das SDK zu verhindern.

  <PropertyGroup>
    <PublishIISAssets>true</PublishIISAssets>
  </PropertyGroup>
  

• Deaktivieren Sie die web.config-Transformation des SDK in der Projektdatei (.csproj):

  <PropertyGroup>
    <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
  </PropertyGroup>
  

• Fügen Sie der Projektdatei (.csproj) ein benutzerdefiniertes Ziel hinzu, um eine benutzerdefinierte web.config-Datei zu verschieben. Im folgenden Beispiel wird die benutzerdefinierte web.config-Datei vom Entwickler im Stammverzeichnis des Projekts platziert. Wenn sich die web.config-Datei an anderer Stelle befindet, geben Sie in SourceFiles den Pfad zur Datei an. Das folgende Beispiel gibt den Ordner publish mit $(PublishDir) an, stellt aber für einen benutzerdefinierten Ausgabespeicherort einen Pfad zu DestinationFolder bereit.

  <Target Name="CopyWebConfig" AfterTargets="Publish">
    <Copy SourceFiles="web.config" DestinationFolder="$(PublishDir)" />
  </Target>
  

Installieren des URL-Rewrite-Moduls

Das URL-Rewrite-Modul wird zum Umschreiben von URLs benötigt. Das Modul wird nicht standardmäßig installiert und ist für die Installation als Webserver (IIS)-Rollendienstfunktion nicht verfügbar. Das Modul muss von der IIS-Website heruntergeladen werden. Verwenden Sie den Webplattform-Installer zur Installation des Moduls:

1. Navigieren Sie lokal zur URL-Rewrite-Module-Downloadseite. Wählen Sie zum Herunterladen der englischen Version des WebPI-Installers WebPI aus. Wählen Sie zum Herunterladen des Installers in einer anderen Sprache die entsprechende Architektur für den Server (x86/x64) aus.
2. Kopieren Sie den Installer auf den Server. Führen Sie den Installer aus. Klicken Sie auf die Schaltfläche Installieren, und stimmen Sie den Lizenzbedingungen zu. Der Server muss nach Abschluss der Installation nicht neu gestartet werden.

Konfigurieren der Website

Legen Sie für den physischen Pfad der Website den Ordner der App fest. Der Ordner enthält Folgendes:

• Die Datei web.config, die von IIS zum Konfigurieren der Website verwendet wird, einschließlich der erforderlichen Umleitungsregeln und Dateiinhaltstypen
• Den Ordner der App für statische Objekte

Hosten als IIS-untergeordnete App

Wenn eine eigenständige App als IIS-untergeordnete App gehostet wird, führen Sie einen der folgenden Schritte aus:

• Deaktivieren Sie den vererbten ASP.NET Core Module-Handler.

  Entfernen Sie den Handler in der veröffentlichen Datei web.config der Blazor-App, indem Sie dem <system.webServer>-Abschnitt der Datei einen <handlers>-Abschnitt hinzufügen:

  <handlers>
    <remove name="aspNetCore" />
  </handlers>
  

• Deaktivieren Sie die Vererbung des <system.webServer>-Abschnitts der Stammanwendung (d. h. der übergeordneten Anwendung), indem Sie ein <location>-Element verwenden, bei dem inheritInChildApplications auf false festgelegt ist:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <handlers>
          <add name="aspNetCore" ... />
        </handlers>
        <aspNetCore ... />
      </system.webServer>
    </location>
  </configuration>
  

  Hinweis

  Die Deaktivierte Vererbung des Abschnitts <system.webServer> der Stamm-App (übergeordneten App) ist die Standardkonfiguration für veröffentlichte App, bei denen das .NET SDK verwendet wird.

Das Entfernen des Handlers bzw. das Deaktivieren der Vererbung wird zusätzlich zur Konfiguration des Basispfads der App durchgeführt. Legen Sie den Basispfad der App in der Datei index.html der App auf den IIS-Alias fest, der beim Konfigurieren der untergeordneten App in IIS verwendet wird.

Konfigurieren Sie den Basispfad der App, indem Sie den Anweisungen im Host folgen und ASP.NET Core-Artikel Blazor bereitstellen.

Brotli- und Gzip-Komprimierung

IIS kann über web.config so konfiguriert werden, dass mit Brotli oder Gzip komprimierte Blazor-Ressourcen für eigenständige Blazor WebAssembly-Apps bereitgestellt werden. Eine Beispielkonfigurationsdatei finden Sie unter web.config.

In den folgenden Szenarien kann eine zusätzliche Konfiguration der Beispieldatei web.config erforderlich sein:

• Die Spezifikation der App erfordert eine der folgenden Aktionen:
  • Bereitstellung komprimierter Dateien, die nicht durch die Beispieldatei web.config konfiguriert sind.
  • Bereitstellung komprimierter Dateien, die durch die Beispieldatei web.config in einem nicht komprimierten Format konfiguriert sind.
• Die IIS-Konfiguration des Servers (z. B. applicationHost.config) stellt IIS-Standardwerte auf Serverebene bereit. Je nach Konfiguration auf Serverebene erfordert die App möglicherweise eine andere IIS-Konfiguration als diejenige, die in der Beispieldatei web.config enthalten ist.

Weitere Informationen zu benutzerdefinierten web.config-Dateien finden Sie im Abschnitt Verwenden einer benutzerdefinierten web.config-Datei.

Problembehandlung

Wenn die Fehlermeldung 500: Interner Serverfehler angezeigt wird und IIS-Manager beim Zugriff auf die Konfiguration der Website eine Fehlermeldung anzeigt, überprüfen Sie, ob das URL-Rewrite-Modul installiert ist. Wenn das Modul nicht installiert ist, kann die Datei web.config nicht von IIS analysiert werden. Dadurch wird verhindert, dass die Konfiguration der Website vom IIS-Manager geladen wird, und dass die statischen Blazor-Dateien auf der Website bereitgestellt werden.

Weitere Informationen zur Problembehandlung bei Bereitstellungen in IIS finden Sie unter Problembehandlung bei ASP.NET Core in Azure App Service und IIS.

Azure Storage

Das Hosten statischer Dateien von Azure Storage ermöglicht das serverlose Blazor-App-Hosting. Benutzerdefinierte Domänennamen, das Azure Content Delivery Network (CDN) und HTTPS werden unterstützt.

Wenn der Blobdienst für das Hosten von statischen Websites in einem Speicherkonto aktiviert ist, gehen Sie folgendermaßen vor:

• Legen Sie den Namen des Indexdokuments auf index.html fest.
• Legen Sie den Pfad des Fehlerdokuments auf index.html fest. Razor-Komponenten und andere Endpunkte, bei denen es sich nicht um Dateien handelt, befinden sich nicht in physischen Pfaden in dem statischen Inhalt, der vom Blobdienst gespeichert wird. Wenn eine Anforderung für eine dieser Ressourcen empfangen wird, die vom Blazor-Router verarbeitet werden soll, leitet der vom Blob-Dienst generierte Fehler 404 – Nicht gefunden die Anforderung an den Pfad des Fehlerdokuments weiter. Das Blob index.html wird zurückgegeben, und der Blazor-Router lädt und verarbeitet den Pfad.

Wenn Dateien aufgrund ungeeigneter MIME-Typen im Content-Type-Headern der Dateien nicht zur Laufzeit geladen werden, führen Sie eine der folgenden Aktionen durch:

• Konfigurieren Sie die Tools so, dass beim Bereitstellen der Dateien die richtigen MIME-Typen (Content-Type-Header) bereitgestellt werden.

• Ändern Sie nach Bereitstellung der App die MIME-Typen (Content-Type-Header) für die Dateien.

  Führen Sie im Storage-Explorer (Azure-Portal) für jede Datei folgende Schritte aus:

  1. Klicken Sie mit der rechten Maustaste auf die Datei, und wählen Sie Eigenschaften aus.
  2. Legen Sie ContentType- fest, und klicken Sie auf die Schaltfläche Speichern

Weitere Informationen finden Sie unter Hosten von statischen Websites in Azure Storage.

Nginx

Die folgende Datei nginx.conf wurde vereinfacht, um zu zeigen, wie Nginx so konfiguriert wird, dass die Datei index.html gesendet wird, wenn auf der Festplatte keine entsprechende Datei gefunden wird.

events { }
http {
    server {
        listen 80;

        location / {
            root      /usr/share/nginx/html;
            try_files $uri $uri/ /index.html =404;
        }
    }
}

Wenn Sie limit_req für das NGINX-Burstratenlimit festlegen, erfordern Blazor WebAssembly-Apps möglicherweise einen größeren burst-Parameterwert, um die relativ große Anzahl an Anforderungen zu erfüllen, die eine App stellen kann. Legen Sie den Wert zunächst auf 60 fest:

http {
    server {
        ...

        location / {
            ...

            limit_req zone=one burst=60 nodelay;
        }
    }
}

Erhöhen Sie den Wert, wenn Browserentwicklertools oder Netzwerkdatenverkehrstools angeben, dass für Anforderungen der Statuscode 503 – Dienst nicht verfügbar zurückgegeben wird.

Weitere Informationen zur Nginx-Webserverkonfiguration für die Produktion finden Sie unter Creating NGINX Plus and NGINX Configuration Files (Erstellen von Konfigurationsdateien für NGINX Plus und NGINX).

Apache

So stellen Sie eine Blazor WebAssembly-App in Apache bereit:

1. Platzieren Sie die Apache-Konfigurationsdatei in das /etc/httpd/conf.d/-Verzeichnis.

2. Platzieren Sie die veröffentlichten Ressourcen der App (/bin/Release/{TARGET FRAMEWORK}/publish/wwwroot, wobei der {TARGET FRAMEWORK}-Platzhalter das Zielframework ist) in das Verzeichnis /var/www/blazorapp (der Speicherort, der in der Konfigurationsdatei für DocumentRoot angegeben ist).

3. Starten Sie den Apache-Dienst neu.

Weitere Informationen finden Sie unter mod_mime und mod_deflate.

GitHub-Seiten

Die GitHub-Standardaktion, mit der Seiten bereitgestellt werden, überspringt die Bereitstellung von Ordnern, deren Namen mit einem Unterstrich beginnen, z. B. den Ordner _framework. Um Ordner bereitzustellen, deren Namen mit einem Unterstrich beginnen, fügen Sie dem Git-Branch eine leere Datei .nojekyll hinzu.

Git behandelt JavaScript-Dateien (JS-Dateien) wie blazor.webassembly.js als Text und konvertiert in der Bereitstellungspipeline Zeilenenden aus CRLF (Wagenrücklauf) in LF (Zeilenvorschub). Diese Änderungen an JS-Dateien generieren andere Dateihashes als Blazor an den Client in der Datei blazor.boot.json sendet. Die Konflikte führen zu Fehlern der Integritätsprüfung auf dem Client. Ein Ansatz zum Beheben dieses Problems besteht darin, eine .gitattributes-Datei mit einer Zeile *.js binary hinzuzufügen, bevor die Ressourcen der App dem Git-Branch hinzugefügt werden. Die Zeile *.js binary konfiguriert Git so, dass JS-Dateien als Binärdateien behandelt werden, wodurch die Verarbeitung der Dateien in der Bereitstellungspipeline vermieden wird. Die Dateihashes der nicht verarbeiteten Dateien stimmen mit den Einträgen in der Datei blazor.boot.json überein, und clientseitige Integritätsprüfungen werden bestanden. Weitere Informationen finden Sie unter ASP.NET Core Blazor WebAssembly .NET Runtime und App Bundle-Zwischenspeicherung.

Fügen Sie zum Verarbeiten von URL-Umschreibungen eine wwwroot/404.html-Datei mit einem Skript hinzu, mit dem die Umleitung der Anforderung an die Seite index.html verarbeitet wird. Ein Beispiel finden Sie im GitHub-Repository SteveSandersonMS/BlazorOnGitHubPages:

• wwwroot/404.html
• Livewebsite

Wenn Sie anstelle einer Organisationswebsite eine Projektwebsite verwenden, aktualisieren Sie das <base>-Tag in wwwroot/index.html. Legen Sie den Wert des href-Attributs auf den Namen des GitHub-Repositorys mit einem nachfolgenden Schrägstrich fest (z. B. /my-repository/). Im GitHub-Repository SteveSandersonMS/BlazorOnGitHubPageswird die href-Basis bei der Veröffentlichung durch die .github/workflows/main.yml-Konfigurationsdatei aktualisiert.

Eigenständig mit Docker

Eine eigenständige Blazor WebAssembly-App wird als Satz statischer Dateien für das Hosting durch einen statischen Dateiserver veröffentlicht.

So hosten Sie die App in Docker

• Wählen Sie einen Docker-Container mit Webserverunterstützung aus, z. B. Ngnix oder Apache.
• Kopieren Sie die Ressourcen im Ordner publish in einen Ordner, der auf dem Webserver für die Bereitstellung statischer Dateien definiert ist.
• Wenden Sie nach Bedarf zusätzliche Konfiguration für die Blazor WebAssembly-App an.

Einen Leitfaden zur Konfiguration finden Sie in den folgenden Ressourcen:

• Abschnitt Nginx oder Apache im vorliegenden Artikel
• Docker-Dokumentation

Hostkonfigurationswerte

Blazor WebAssembly-Apps können die folgenden Hostkonfigurationswerte als Befehlszeilenargumente zur Runtime in der Entwicklungsumgebung akzeptieren.

Inhaltsstammverzeichnis

Mit dem Argument --contentroot wird der absolute Pfad zum Verzeichnis festgelegt, das die Inhaltsdateien (das Inhaltsstammverzeichnis) der App enthält. In den folgenden Beispielen ist /content-root-path der Stammpfad für Inhalte der App.

• Das Argument wird beim lokalen Ausführen der App bei einer Eingabeaufforderung übergeben. Führen Sie den folgenden Befehl über das Verzeichnis der App aus:

  dotnet watch --contentroot=/content-root-path
  

• Fügen Sie der Datei launchSettings.json der App im Profil IIS Express einen Eintrag hinzu. Diese Einstellung wird verwendet, wenn die Anwendung mit dem Visual Studio-Debugger und an einer Eingabeaufforderung mit dotnet watch (oder dotnet run) ausgeführt wird.

  "commandLineArgs": "--contentroot=/content-root-path"
  

• Geben Sie in Visual Studio das Argument in Eigenschaften>Debuggen>Anwendungsargumente ein. Wenn Sie das Argument auf der Visual Studio-Eigenschaftenseite festlegen, wird das Argument der Datei launchSettings.json hinzugefügt.

  --contentroot=/content-root-path
  

Basispfad

Mit dem Argument --pathbase wird der Basispfad für eine App festgelegt, die lokal mit einem relativen URL-Pfad ausgeführt wird, der sich nicht im Stammverzeichnis befindet (d. h. das <base>-Tag href wird für das Staging und die Produktion auf einen anderen Pfad als / festgelegt). In den folgenden Beispielen ist /relative-URL-path die Pfadbasis der App. Weitere Informationen finden Sie unter Basispfad einer App.

• Das Argument wird beim lokalen Ausführen der App bei einer Eingabeaufforderung übergeben. Führen Sie den folgenden Befehl über das Verzeichnis der App aus:

  dotnet watch --pathbase=/relative-URL-path
  

• Fügen Sie der Datei launchSettings.json der App im Profil IIS Express einen Eintrag hinzu. Diese Einstellung wird verwendet, wenn die Anwendung mit dem Visual Studio-Debugger und an einer Eingabeaufforderung mit dotnet watch (oder dotnet run) ausgeführt wird.

  "commandLineArgs": "--pathbase=/relative-URL-path"
  

• Geben Sie in Visual Studio das Argument in Eigenschaften>Debuggen>Anwendungsargumente ein. Wenn Sie das Argument auf der Visual Studio-Eigenschaftenseite festlegen, wird das Argument der Datei launchSettings.json hinzugefügt.

  --pathbase=/relative-URL-path
  

URLs

Mit dem Argument --urls werden die IP-oder Hostadressen mit Ports und Protokollen festgelegt, die auf Anforderungen lauschen sollen.

• Das Argument wird beim lokalen Ausführen der App bei einer Eingabeaufforderung übergeben. Führen Sie den folgenden Befehl über das Verzeichnis der App aus:

  dotnet watch --urls=http://127.0.0.1:0
  

• Fügen Sie der Datei launchSettings.json der App im Profil IIS Express einen Eintrag hinzu. Diese Einstellung wird verwendet, wenn die Anwendung mit dem Visual Studio-Debugger und an einer Eingabeaufforderung mit dotnet watch (oder dotnet run) ausgeführt wird.

  "commandLineArgs": "--urls=http://127.0.0.1:0"
  

• Geben Sie in Visual Studio das Argument in Eigenschaften>Debuggen>Anwendungsargumente ein. Wenn Sie das Argument auf der Visual Studio-Eigenschaftenseite festlegen, wird das Argument der Datei launchSettings.json hinzugefügt.

  --urls=http://127.0.0.1:0
  

dir {PATH} | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content {PATH}\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\blazor.boot.json

((Get-Content {PATH}\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\service-worker-assets.js

for f in {PATH}/*; do mv "$f" "`echo $f | sed -e 's/\.dll/.bin/g'`"; done
sed -i 's/\.dll"/.bin"/g' {PATH}/blazor.boot.json

sed -i 's/\.dll"/.bin"/g' {PATH}/service-worker-assets.js

param([string]$filepath,[string]$tfm)
dir $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json.br

((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js.br

<Target Name="ChangeDLLFileExtensions" AfterTargets="AfterPublish" Condition="'$(Configuration)'=='Release'">
  <Exec Command="powershell.exe -command &quot;&amp; { .\ChangeDLLExtensions.ps1 '$(SolutionDir)' '$(TargetFramework)'}&quot;" />
</Target>

<staticContent>
  ...
  <mimeMap fileExtension=".bin" mimeType="application/octet-stream" />
  ...
</staticContent>

<mimeMap fileExtension=".bin.br" mimeType="application/octet-stream" />
<mimeMap fileExtension=".bin.gz" mimeType="application/octet-stream" />

- <mimeMap fileExtension=".dll" mimeType="application/octet-stream" />

- <mimeMap fileExtension=".dll.br" mimeType="application/octet-stream" />
- <mimeMap fileExtension=".dll.gz" mimeType="application/octet-stream" />

Beschädigung durch Dateien aus einer früheren Bereitstellung

Typisch bei Bereitstellungen:

• Nur die geänderten Dateien werden ersetzt, was in der Regel zu einer schnelleren Bereitstellung führt.
• Vorhandene Dateien, die nicht Teil der neuen Bereitstellung sind, bleiben für die Verwendung durch die neue Bereitstellung erhalten.

In seltenen Fällen kann eine neue Bereitstellung durch veraltete Dateien aus einer vorherigen Bereitstellung beschädigt werden. Wenn Sie die vorhandene Bereitstellung (oder die lokal veröffentlichte App vor der Bereitstellung) vollständig löschen, wird das Problem mit einer beschädigten Bereitstellung möglicherweise behoben. Häufig reicht es aus, die vorhandene Bereitstellung einmal zu löschen, um das Problem auch bei einer DevOps-Build- und -Bereitstellungspipeline zu beheben.

Wenn Sie feststellen, dass das Löschen einer vorherigen Bereitstellung immer erforderlich ist, wenn eine DevOps-Build- und -Bereitstellungspipeline verwendet wird, können Sie der Buildpipeline vorübergehend einen Schritt hinzufügen, um die vorherige Bereitstellung für jede neue Bereitstellung zu löschen, bis Sie die genaue Ursache der Beschädigung behoben haben.

Lösen von Fehlern bei der Integritätsprüfung

Wenn Blazor WebAssembly die Startdateien einer App herunterlädt, wird der Browser angewiesen, Integritätsprüfungen der Antworten auszuführen. Blazor sendet SHA-256 Hash-Werte für DLL- (.dll), WebAssembly- (.wasm) und andere Dateien in der Datei blazor.boot.json, die auf Clients nicht zwischengespeichert wird. Die Dateihashes zwischengespeicherter Dateien werden mit den Hashes in der Datei blazor.boot.json verglichen. Für zwischengespeicherte Dateien mit einem übereinstimmenden Hashwert verwendet Blazor die zwischengespeicherten Dateien. Andernfalls werden Dateien vom Server angefordert. Nach dem Herunterladen einer Datei wird ihr Hash erneut auf Integrität geprüft. Der Browser generiert eine Fehlermeldung, wenn die Integritätsprüfung einer heruntergeladenen Datei fehlschlägt.

Der Algorithmus von Blazor zur Verwaltung der Integrität von Dateien:

• Stellt sicher, dass kein inkonsistenter Satz von Dateien geladen wird, wenn z. B. eine neue Bereitstellung auf den Webserver angewendet wird, während der Benutzer gerade die Anwendungsdateien herunterlädt. Inkonsistente Dateien können zu einer fehlerhaften App führen.
• Stellt sicher, dass der Browser des Benutzers keine inkonsistenten oder ungültigen Antworten zwischenspeichert, wodurch der Start der App verhindert werden kann, selbst wenn der Benutzer die Seite manuell aktualisiert.
• Ermöglicht eine sichere Zwischenspeicherung der Antworten und prüft erst dann auf serverseitige Änderungen, wenn sich die erwarteten SHA-256-Hashes selbst ändern, sodass nachfolgende Seitenladevorgänge weniger Anforderungen umfassen und schneller abgeschlossen werden.

Wenn der Webserver Antworten zurückgibt, die nicht den erwarteten SHA-256-Hashwerten entsprechen, wird in der Entwicklerkonsole des Browsers eine Fehlermeldung angezeigt, die dem folgenden Beispiel ähnelt:

Fehler bei der Suche nach einem gültigen Digest im Attribut 'integrity' für die Ressource 'https://myapp.example.com/_framework/MyBlazorApp.dll' mit berechneter SHA-256-Integrität'IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY='. The resource has been blocked. (Fehler beim Ermitteln eines gültigen Hashs im 'integrity'-Attribut für die Ressource 'https://myapp.example.com/_framework/MyBlazorApp.dll' mit der berechneten SHA-256-Integrität 'IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY='. Die Ressource wurde blockiert.)

In den meisten Fällen gibt die Warnung kein Problem mit der Integritätsprüfung an. Stattdessen bedeutet die Warnung normalerweise, dass ein anderes Problem vorliegt.

Den Verweis auf die Startquelle von Blazor WebAssembly finden Sie in der Datei Boot.WebAssembly.ts im dotnet/aspnetcore GitHub-Repository.

Diagnostizieren von Integritätsproblemen

Wenn eine App erstellt wird, beschreibt das generierte blazor.boot.json-Manifest die SHA-256-Hashwerte der Startressourcen zum Zeitpunkt der Erstellung der Buildausgabe. Die Integritätsprüfung wird durchgeführt, solange die SHA-256-Hashwerte in blazor.boot.json mit den Dateien, die an den Browser übermittelt werden, übereinstimmen.

Häufige Ursachen für Fehler sind unter anderem:

• Die Antwort des Webservers ist eine Fehlermeldung (z. B. 404 – nicht gefunden oder 500 – Interner Serverfehler) anstelle der vom Browser angeforderten Datei. Dies wird vom Browser als Fehler bei der Integritätsprüfung gemeldet, nicht als Antwortfehler.
• Der Inhalt der Dateien wurde zwischen dem Build und der Übermittlung der Dateien an den Browser geändert. Dies kann vorkommen:
  • Wenn Sie oder Buildtools die Buildausgabe manuell ändern.
  • Wenn ein Aspekt des Bereitstellungsprozesses die Dateien geändert hat. Wenn Sie z. B. einen Bereitstellungsmechanismus auf Git-Basis verwenden, bedenken Sie, dass Git die Zeilenenden im Windows-Format transparent in UNIX-Zeilenenden konvertiert, wenn Sie Dateien unter Windows übertragen und unter Linux auschecken. Durch das Ändern von Dateizeilenenden werden die SHA-256-Hashwerte geändert. Um dieses Problem zu vermeiden, sollten Sie die Verwendung von .gitattributes erwägen, um Buildartefakte als binary-Dateien zu behandeln.
  • Der Webserver ändert Dateiinhalte im Rahmen ihrer Bereitstellung. Einige Content Distribution Networks (CDNs) versuchen z. B. automatisch, HTML zu minimieren und damit zu ändern. Sie müssen diese Features möglicherweise deaktivieren.
• Die Datei blazor.boot.json wird nicht ordnungsgemäß geladen oder ist auf dem Client nicht richtig zwischengespeichert. Es folgen die häufigsten Ursachen:
  • Falsch konfigurierter oder fehlerhafter benutzerdefinierter Entwicklercode.
  • Eine oder mehrere falsch konfigurierte Zwischencacheebenen.

So diagnostizieren Sie, was davon in Ihrem Fall zutrifft:

1. Beachten Sie, welche Datei den Fehler auslöst, indem Sie die Fehlermeldung lesen.
2. Öffnen Sie die Entwicklertools Ihres Browsers, und sehen Sie sich die Registerkarte Netzwerk an. Laden Sie ggf. die Seite erneut, um die Liste der Anforderungen und Antworten anzuzeigen. Suchen Sie die Datei, die den in dieser Liste ausgeführten Fehler auslöst.
3. Überprüfen Sie den HTTP-Statuscode in der Antwort. Wenn der Server etwas anderes als 200 – OK (oder einen anderen 2xx-Statuscode) zurückgibt, müssen Sie ein serverseitiges Problem diagnostizieren. Der Statuscode 403 bedeutet beispielsweise, dass ein Autorisierungsproblem vorliegt, während der Statuscode 500 bedeutet, dass ein nicht angegebener Serverfehler aufgetreten ist. Untersuchen Sie serverseitige Protokolle, um die App zu diagnostizieren und zu korrigieren.
4. Wenn der Statuscode für die Ressource 200 – OK lautet, sehen Sie sich den Antwortinhalt in den Entwicklertools des Browsers an, und überprüfen Sie, ob der Inhalt mit den erwarteten Daten übereinstimmt. Ein häufiges Problem ist beispielsweise die falsche Konfiguration des Routings, sodass Anforderungen Ihre index.html-Daten auch für andere Dateien zurückgeben. Stellen Sie sicher, dass Antworten auf .wasm-Anforderungen WebAssembly-Binärdateien und Antworten auf .dll-Anforderungen .NET-Assembly-Binärdateien sind. Wenn dies nicht der Fall ist, müssen Sie ein serverseitiges Routingproblem diagnostizieren.
5. Überprüfen Sie die veröffentlichte und bereitgestellte Ausgabe der App mithilfe des PowerShell-Skripts für die Behebung von Problemen bei der Integrität.

Wenn Sie sich vergewissert haben, dass der Server überzeugend korrekte Daten zurückgibt, muss irgendetwas anderes zwischen Build und Übermittlung der Datei den Inhalt ändern. So ermitteln Sie dies:

• Untersuchen Sie die Buildtoolkette und den Bereitstellungsmechanismus darauf hin, ob sie Dateien nach dem Erstellen ändern. Dies ist beispielsweise der Fall, wenn Git wie zuvor beschrieben Dateizeilenenden transformiert.
• Untersuchen Sie den Webserver oder die CDN-Konfiguration darauf hin, ob sie so eingerichtet sind, dass Antworten dynamisch geändert werden (z. B. der Versuch, HTML zu minimieren). Es ist in Ordnung, dass der Webserver die HTTP-Komprimierung implementiert (z. B. Rückgabe von content-encoding: br oder content-encoding: gzip), da dies das Ergebnis nach der Dekomprimierung nicht beeinträchtigt. Es ist jedoch nicht in Ordnung, dass der Webserver die nicht komprimierten Daten ändert.

PowerShell-Skript für die Behebung von Problemen bei der Integrität

Verwenden Sie das PowerShell-Skript integrity.ps1 zum Überprüfen einer veröffentlichten und bereitgestellten Blazor-App. Das Skript wird für PowerShell Core 7 oder höher als Startpunkt zur Behebung von Integritätsproblemen mit der App bereitgestellt, die vom Blazor-Framework nicht identifiziert werden können. Möglicherweise ist eine Anpassung des Skripts für Ihre Apps erforderlich, z. B. bei der Ausführung unter einer Version von PowerShell höher als Version 7.2.0.

Das Skript überprüft die Dateien im Ordner publish sowie die von der bereitgestellten App heruntergeladenen Dateien, um Probleme in den verschiedenen Manifesten zu erkennen, die Integritätshashes enthalten. Mit diesen Prüfungen sollten sich die häufigsten Probleme erkennen lassen:

• Sie haben eine Datei in der veröffentlichten Ausgabe geändert, ohne es zu bemerken.
• Die App wurde nicht ordnungsgemäß im Bereitstellungsziel bereitgestellt, oder etwas hat sich in der Umgebung des Bereitstellungsziels geändert.
• Es gibt Unterschiede zwischen der bereitgestellten App und der Ausgabe der Veröffentlichung der App.

Rufen Sie das Skript mit dem folgenden Befehl in einer PowerShell-Befehlsshell auf:

.\integrity.ps1 {BASE URL} {PUBLISH OUTPUT FOLDER}

Im folgenden Beispiel wird das Skript für eine lokal ausgeführte App unter https://localhost:5001/ ausgeführt:

.\integrity.ps1 https://localhost:5001/ C:\TestApps\BlazorSample\bin\Release\net6.0\publish\

Platzhalter:

• {BASE URL}: Die URL der bereitgestellten App. Ein nachgestellter Schrägstrich (/) ist erforderlich.
• {PUBLISH OUTPUT FOLDER}: Der Pfad zum publish-Ordner der App oder zu dem Speicherort, in dem die App für die Bereitstellung veröffentlicht wurde.

C:\Users\{USER}\Documents\GitHub\AspNetCore.Docs\aspnetcore\blazor\host-and-deploy\webassembly\_samples\integrity.ps1

CertUtil -hashfile {PATH AND FILE NAME} {SHA256|MD5}

Deaktivieren der Integritätsprüfung für Nicht-PWA-Apps

Deaktivieren Sie die Integritätsprüfung in den meisten Fällen nicht. Das Deaktivieren der Integritätsprüfung löst nicht das zugrunde liegende Problem, das die unerwarteten Antworten verursacht hat, und führt zu einem Verlust der zuvor aufgeführten Vorteile.

Es kann vorkommen, dass Sie sich nicht darauf verlassen können, dass der Webserver konsistente Antworten zurückgibt, und Sie keine andere Wahl haben, als die Integritätsprüfungen vorübergehend zu deaktivieren, bis das zugrunde liegende Problem behoben ist.

Um die Integritätsprüfungen zu deaktivieren, fügen Sie einer Eigenschaftsgruppe in der Projektdatei der App Blazor WebAssembly (.csproj) Folgendes hinzu:

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResources deaktiviert auch das Standardverhalten von Blazor beim Zwischenspeichern der .dll-, .wasm- und anderer Dateien auf der Grundlage ihrer SHA-256-Hashwerte, da die Eigenschaft angibt, dass die Richtigkeit der SHA-256-Hashwerte nicht verlässlich ist. Auch mit dieser Einstellung kann der normale HTTP-Cache des Browsers diese Dateien weiterhin zwischenspeichern. Ob dies der Fall ist, hängt von der Konfiguration Ihres Webservers und den cache-control-Headern ab, die er bedient.

Wir können keine vollständige Liste der Szenarien erstellen, in denen eine Deaktivierung der Integritätsprüfung erforderlich ist. Server können eine Anforderung auf beliebige Weise außerhalb des Geltungsbereichs des Blazor-Frameworks beantworten. Das Framework bietet die Einstellung BlazorCacheBootResources, um die App ausführbar zu machen, allerdings um den Preis des Verlusts einer Integritätsgarantie, die die App bieten kann. Auch hier raten wir davon ab, die Integritätsprüfung zu deaktivieren, insbesondere bei Bereitstellungen in der Produktion. Entwickler sollten versuchen, das zugrunde liegende Integritätsproblem zu lösen, das dazu führt, dass die Integritätsprüfung fehlschlägt.

Es folgen einige allgemeine Fälle, die Integritätsprobleme verursachen können:

• Ausführung über HTTP, wobei keine Integritätsprüfung durchgeführt werden kann.
• Wenn Ihr Bereitstellungsprozess die Dateien nach der Veröffentlichung in beliebiger Weise modifiziert.
• Wenn Ihr Host die Dateien in beliebiger Weise modifiziert.

Deaktivieren der Integritätsprüfung für PWAs

Die Vorlage für progressive Webanwendungen (Progressive Web Applications, PWAs) von Blazor enthält eine vorgeschlagene service-worker.published.js-Datei, die für das Abrufen und Speichern von Anwendungsdateien für die Offlineverwendung zuständig ist. Dabei handelt es sich um einen vom normalen App-Startmechanismus separaten Prozess, der über eine eigene, separate Logik zur Integritätsprüfung verfügt.

Die service-worker.published.js-Datei enthält folgende Zeile:

.map(asset => new Request(asset.url, { integrity: asset.hash }));

Entfernen Sie zum Deaktivieren der Integritätsprüfung den integrity-Parameter, indem Sie die Zeile wie folgt ändern:

.map(asset => new Request(asset.url));

Noch einmal: Das Deaktivieren der Integritätsprüfung bedeutet, dass Sie die Sicherheitsgarantien verlieren, die die Integritätsprüfung bietet. Beispielsweise besteht folgendes Risiko: Wenn der Browser des Benutzers genau in dem Moment, in dem Sie eine neue Version bereitstellen, die App zwischenspeichert, könnte er einige Dateien aus der alten und einige aus der neuen Bereitstellung zwischenspeichern. Wenn dies der Fall ist, bleibt die App in einem defekten Zustand, bis Sie ein weiteres Update bereitstellen.