Freigeben über

Vermeiden von Problemen beim Zwischenspeichern von HTTP beim Upgrade von ASP.NET Core Blazor-Apps

  • Artikel

Hinweis

Dies ist nicht die neueste Version dieses Artikels. Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.

Warnung

Diese Version von ASP.NET Core wird nicht mehr unterstützt. Weitere Informationen finden Sie in der .NET- und .NET Core-Supportrichtlinie. Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.

Wichtig

Diese Informationen beziehen sich auf ein Vorabversionsprodukt, das vor der kommerziellen Freigabe möglicherweise noch wesentlichen Änderungen unterliegt. Microsoft gibt keine Garantie, weder ausdrücklich noch impliziert, hinsichtlich der hier bereitgestellten Informationen.

Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.

Wenn Blazor Apps fälschlicherweise aktualisiert oder konfiguriert wurden, kann es zu nicht nahtlosen Upgrades für vorhandene Benutzer*innen führen. In diesem Artikel werden einige der häufig auftretenden Probleme beim Zwischenspeichern von HTTP erläutert, die beim Upgraden von Blazor-Apps auf Hauptversionen auftreten können. Außerdem werden einige empfohlene Aktionen bereitgestellt, um einen reibungslosen Übergang für Ihre Benutzer*innen sicherzustellen.

Während zukünftige Blazor-Versionen möglicherweise bessere Lösungen für den Umgang mit HTTP-Caching-Problemen bieten, liegt es letztendlich an der App, die Zwischenspeicherung ordnungsgemäß zu konfigurieren. Durch die ordnungsgemäße Konfiguration der Zwischenspeicherung wird sichergestellt, dass die Benutzer*innen der App immer über die aktuellste Version der App verfügen und so ihre Benutzererfahrung verbessert und die Wahrscheinlichkeit von Fehlern verringert wird.

Häufige Probleme, die sich negativ auf die Benutzerupgradeerfahrung auswirken, umfassen:

  • Falsche Behandlung von Projekt- und Paketupdates: Dies geschieht, wenn Sie nicht alle bereitgestellten Projekte der App aktualisieren, damit diese dieselbe Hauptframeworkversion zu verwenden, oder wenn Sie Pakete aus einer früheren Version verwenden, obwohl eine neuere Version als Teil des Hauptupgrades verfügbar ist.
  • Falsche Konfiguration von Cacheheadern: HTTP-Cacheheader steuern, wie, wo und wie lange die Antworten der App zwischengespeichert werden. Wenn Header nicht ordnungsgemäß konfiguriert sind, erhalten Benutzer*innen möglicherweise veraltete Inhalte.
  • Falsche Konfiguration anderer Ebenen: Content Delivery Networks (CDNs) und andere Ebenen der bereitgestellten App können Probleme verursachen, wenn sie falsch konfiguriert sind. Zum Beispiel sind CDNs für das Zwischenspeichern und Bereitstellen von Inhalten konzipiert, um die Leistung zu verbessern und die Latenz zu verringern. Wenn ein CDN fälschlicherweise zwischengespeicherte Versionen von Objekten bedient, kann veralteter Inhalt an Benutzer*innen übermittelt werden.

Erkennen und Diagnostizieren von Upgradeproblemen

Upgradeprobleme werden in der Regel als Fehler beim Starten der App im Browser angezeigt. Normalerweise weist eine Warnung auf das Vorhandensein eines veralteten Elements oder einer Ressource, die fehlt oder nicht mit der App kompatibel ist, hin.

  • Überprüfen Sie zunächst, ob die App in einer sauberen Browserinstanz erfolgreich geladen werden kann. Verwenden Sie einen privaten Browsermodus, um die App zu laden, z. B. den InPrivate-Modus von Microsoft Edge oder den Google Chrome Inkognito-Modus. Wenn die App nicht geladen werden kann, bedeutet dies wahrscheinlich, dass mindestens ein Paket oder das Framework nicht ordnungsgemäß aktualisiert wurde.
  • Wenn die App in einer sauberen Browserinstanz ordnungsgemäß geladen wird, wird die App wahrscheinlich aus einem veralteten Cache bereitgestellt. In den meisten Fällen leert eine harte Browseraktualisierung mit STRG+F5 den Cache, wodurch die App mit den neuesten Ressourcen geladen und ausgeführt werden kann.
  • Wenn die App weiterhin fehlschlägt, ist es wahrscheinlich, dass ein veralteter CDN-Cache die App bedient. Versuchen Sie, den DNS-Cache über den von Ihrem CDN-Anbieter angebotenen Mechanismus zu leeren.

Der vorherige Prozess für die App-Bereitstellung erschwert den Updateprozess möglicherweise. Beispielsweise kann das Vermeiden oder falsche Verwenden von Zwischenspeicherungsheadern in der Vergangenheit zu Zwischenspeicherungsproblemen zum jetzigen Zeitpunkt für Benutzer*innen führen. Sie können die Aktionen in den folgenden Abschnitten ausführen, um das Problem zu beheben und den Upgradeprozess für Benutzer*innen zu verbessern.

Ausrichten von Frameworkpaketen mit der Frameworkversion

Stellen Sie sicher, dass Frameworkpakete mit der Frameworkversion übereinstimmen. Wenn Pakete aus einer früheren Version verwendet werden, obwohl eine neuere Version verfügbar ist, kann dies zu Kompatibilitätsproblemen führen. Es ist auch wichtig sicherzustellen, dass alle bereitgestellten Projekte der App dieselbe Hauptframeworkversion verwenden. Diese Konsistenz trägt dazu bei, unerwartetes Verhalten und Fehler zu vermeiden.

Überprüfen des Vorhandenseins korrekter Zwischenspeicherungsheader

Die richtigen Zwischenspeicherungsheader sollten für Antworten auf Ressourcenanforderungen vorhanden sein. Dazu gehören ETag, Cache-Controlund andere Zwischenspeicherungsheader. Die Konfiguration dieser Header hängt vom Hostingdienst oder von der Hostingserverplattform ab. Sie sind besonders wichtig für Ressourcen wie das Blazor-Skript (blazor.webassembly.js) und alles, was das Skript herunterlädt.

Falsche HTTP-Cacheheader können sich auch auf Dienstworker auswirken. Dienstworker verlassen sich auf die Zwischenspeicherung von Headern, um zwischengespeicherte Ressourcen effektiv zu verwalten. Daher können falsche oder fehlende Header die Funktionalität des Dienstworkers stören.

Verwenden von Clear-Site-Data, um den Zustand im Browser zu löschen

Erwägen Sie die Verwendung des Clear-Site-Data-Headers, um den Zustand im Browser zu löschen.

In der Regel sind Cachestatusprobleme auf den HTTP-Browsercache zurückzuführen, daher sollte die Verwendung der cache-Anweisung ausreichend sein. Mit dieser Aktion kann sichergestellt werden, dass der Browser die neuesten Ressourcen vom Server abruft, anstatt veraltete Inhalte aus dem Cache zu verarbeiten.

Sie können optional die storage-Anweisung einschließen, um lokale Speichercaches gleichzeitig zu löschen, während Sie den HTTP-Browsercache löschen. Apps, die den Clientspeicher verwenden, können jedoch einen Verlust wichtiger Informationen feststellen, wenn die storage-Anweisung verwendet wird.

Anfügen einer Abfragezeichenfolge an das Blazor-Skripttag

Wenn keine der vorherigen empfohlenen Aktionen wirksam ist, für die Bereitstellung verwendet oder auf Ihre App angewendet werden kann, erwägen Sie, vorübergehend eine Abfragezeichenfolge an die <script>-Tagquelle des Blazor-Skripts anzufügen. Diese Aktion sollte in den meisten Situationen ausreichen, um zu erzwingen, dass der Browser den lokalen HTTP-Cache umgeht und eine neue Version der App herunterlädt. Die Abfragezeichenfolge in der App muss nicht gelesen oder verwendet werden.

Im folgenden Beispiel wird die Abfragezeichenfolge „temporaryQueryString=1“ vorübergehend auf den relativen externen Quell-URI des <script>-Tags angewendet:

<script src="_framework/blazor.webassembly.js?temporaryQueryString=1"></script>

Nachdem alle Benutzer*innen der App die App neu geladen haben, kann die Abfragezeichenfolge entfernt werden.

Alternativ können Sie eine persistente Abfragezeichenfolge mit relevanter Versionsverwaltung anwenden. Im folgenden Beispiel wird davon ausgegangen, dass die Version der App mit der .NET-Version übereinstimmt (8 für .NET 8):

<script src="_framework/blazor.webassembly.js?version=8"></script>

Informationen zum Speicherort des Blazor-Skripts <script> Tags finden Sie unter ProjektstrukturBlazor für ASP.NET Core.