Dela via

Undvik problem med HTTP-cachelagring när du uppgraderar ASP.NET Core-appar Blazor

  • Artikel

Anmärkning

Det här är inte den senaste versionen av den här artikeln. För den nuvarande utgåvan, se .NET 9-versionen av den här artikeln .

Varning

Den här versionen av ASP.NET Core stöds inte längre. Mer information finns i .NET och .NET Core Support Policy. För den nuvarande utgåvan, se .NET 9-versionen av den här artikeln .

Viktigt!

Den här informationen gäller en förhandsversionsprodukt som kan ändras avsevärt innan den släpps kommersiellt. Microsoft lämnar inga garantier, uttryckliga eller underförstådda, med avseende på den information som tillhandahålls här.

För den nuvarande utgåvan, se .NET 9-versionen av den här artikeln .

Den här artikeln beskriver hur du undviker problem med HTTP-cachelagring när du uppgraderar Blazor appar.

När Blazor appar uppgraderas eller konfigureras felaktigt kan det resultera i icke-sömlösa uppgraderingar för befintliga användare. I den här artikeln beskrivs några vanliga problem med HTTP-cachelagring som kan uppstå när du uppgraderar Blazor appar mellan större versioner. Det innehåller också några rekommenderade åtgärder för att säkerställa en smidig övergång för dina användare.

Även om framtida Blazor versioner kan ge bättre lösningar för att hantera PROBLEM med HTTP-cachelagring är det i slutändan upp till appen att konfigurera cachelagring korrekt. Korrekt cachelagringskonfiguration säkerställer att appens användare alltid har den mest up-to-datum-versionen av appen, vilket förbättrar deras upplevelse och minskar sannolikheten för att stöta på fel.

Vanliga problem som påverkar användaruppgraderingsupplevelsen negativt är:

  • Felaktig hantering av projekt- och paketuppdateringar: Detta händer om du inte uppdaterar alla appens distribuerade projekt för att använda samma huvudramverksversion eller om du använder paket från en tidigare version när en nyare version är tillgänglig som en del av den större uppgraderingen.
  • Felaktig konfiguration av cachelagringshuvuden: HTTP-cachelagringshuvuden styr hur, var och hur länge appens svar cachelagras. Om rubrikerna inte är korrekt konfigurerade kan användarna få inaktuellt innehåll.
  • Felaktig konfiguration av andra lager: Innehållsleveransnätverk (CDN) och andra lager i den distribuerade appen kan orsaka problem om de är felaktigt konfigurerade. Till exempel är CDN:er utformade för att cachelagra och leverera innehåll för att förbättra prestanda och minska latens. Om ett CDN felaktigt hanterar cachelagrade versioner av tillgångar kan det leda till inaktuell innehållsleverans till användaren.

Identifiera och diagnostisera uppgraderingsproblem

Uppgraderingsproblem visas vanligtvis som ett fel när appen startas i webbläsaren. Normalt anger en varning förekomsten av en inaktuell tillgång eller en tillgång som saknas eller är inkonsekvent med appen.

  • Kontrollera först om appen laddas framgångsrikt i en ren webbläsarinstans. Använd ett privat webbläsarläge för att läsa in appen, till exempel Microsoft Edge InPrivate-läge eller Google Chrome Incognito-läge. Om appen inte kan läsas in innebär det sannolikt att ett eller flera paket eller ramverket inte uppdaterades korrekt.
  • Om appen läses in korrekt i en ren webbläsarinstans är det sannolikt att appen lagras i en inaktuell cache. I de flesta fall rensar en hård webbläsaruppdatering med Ctrl+F5 cacheminnet, vilket gör att appen kan läsa in och köra med de senaste tillgångarna.
  • Om appen fortsätter att misslyckas är det troligt att en inaktuell CDN-cache betjänar appen. Försök att rensa DNS-cachen via vilken mekanism din CDN-provider erbjuder.

Den tidigare processen för att betjäna appen kan göra uppdateringsprocessen mer utmanande. Till exempel kan undvikande eller felaktig användning av cachehuvuden tidigare leda till aktuella cacheproblem för användare. Du kan vidta åtgärderna i följande avsnitt för att åtgärda problemet och förbättra uppgraderingsprocessen för användare.

Anpassa ramverkspaket med ramverksversionen

Se till att ramverkspaketen överensstämmer med ramverksversionen. Om du använder paket från en tidigare version när en nyare version är tillgänglig kan det leda till kompatibilitetsproblem. Det är också viktigt att se till att alla appens distribuerade projekt använder samma huvudversion av ramverket. Denna konsekvens hjälper till att undvika oväntat beteende och fel.

Kontrollera förekomsten av rätt cachrubriker

Rätt cachelagringshuvuden ska finnas i svaren på resursbegäranden. Detta inkluderar ETag, Cache-Control, och andra cachelagringshuvuden. Konfigurationen av dessa huvuden är beroende av värdtjänsten eller värdserverplattformen. De är särskilt viktiga för tillgångar som skriptet Blazor (blazor.webassembly.js) och allt som skriptet laddar ned.

Felaktiga cachehuvuden kan också påverka servicearbetare. Servicearbetare förlitar sig på cachehuvuden för att effektivt hantera cachelagrade resurser. Därför kan felaktiga eller saknade rubriker störa servicearbetarens funktioner.

Använd Clear-Site-Data för att ta bort tillstånd i webbläsaren

Överväg att använda Clear-Site-Data rubriken för att ta bort tillståndet i webbläsaren.

Vanligtvis är källan till cachetillståndsproblem begränsad till HTTP-webbläsarens cacheminne, så användningen av cache direktivet bör vara tillräcklig. Den här åtgärden kan hjälpa dig att se till att webbläsaren hämtar de senaste resurserna från servern i stället för att hantera inaktuellt innehåll från cacheminnet.

Du kan också inkludera storage direktivet för att rensa lokala lagringscacheminnen samtidigt som du rensar HTTP-webbläsarens cacheminne. Appar som använder klientlagring kan dock förlora viktig information om storage direktivet används.

Lägg till en frågesträng i skripttaggen Blazor

Om ingen av de tidigare rekommenderade åtgärderna är effektiva, kan användas för distributionen eller tillämpas på din app kan du överväga att tillfälligt lägga till en frågesträng i skriptets Blazor<script> taggkälla. Den här åtgärden bör räcka i de flesta fall för att tvinga webbläsaren att kringgå den lokala HTTP-cachen och ladda ned en ny version av appen. Du behöver inte läsa eller använda frågesträngen i appen.

I följande exempel tillämpas frågesträngen temporaryQueryString=1 tillfälligt på taggens <script> relativa externa käll-URI:

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

När alla appens användare har läst in appen igen kan frågesträngen tas bort.

Du kan också använda en beständig frågesträng med relevant versionshantering. I följande exempel förutsätts att versionen av appen matchar .NET-versionen (8 för .NET 8):

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

Platsen för skripttaggen <script> finns i ASP.NET Core-projektstrukturBlazor.Blazor