Vara värd för och distribuera ASP.NET Core Blazor WebAssembly

Den här artikeln beskriver hur du är värd för och distribuerar Blazor WebAssembly med hjälp av ASP.NET Core, Content Delivery Networks (CDN), filservrar och GitHub Pages.

Med Blazor WebAssembly värdmodell:

• Blazor-appen, dess beroenden och .NET-runtime laddas ned till webbläsaren parallellt.
• Appen körs direkt i webbläsarens användargränssnittstråd.

Den här artikeln gäller distributionsscenariot där den Blazor appen placeras på en statisk värdwebbserver eller tjänst. .NET används inte för att hantera Blazor-appen. Den här strategin beskrivs i avsnittet fristående distribution, som innehåller information om att vara värd för en Blazor WebAssembly-applikation som en underapplikation i IIS.

Underdomän- och IIS-värdtjänster för underprogram

Underdomänvärdar kräver inte någon särskild konfiguration av appen. Du inte behöver konfigurera appens bassökväg (taggen <base> i wwwroot/index.html) som värd för appen i en underdomän.

IIS-underprogram som är värd för kräver att du anger appens bassökväg. För mer information och korslänkar till ytterligare vägledning om värdtjänster för IIS-underapplikationer, se Värd och distribuera ASP.NET Core Blazor.

Minska maximal heapstorlek för vissa webbläsare på mobila enheter

När du skapar en Blazor app som körs på klienten (.Client projekt för en Blazor Web App eller fristående Blazor WebAssembly app) och riktar sig till mobila enhetswebbläsare, särskilt Safari på iOS, kan det krävas att minska det maximala minnet för appen med egenskapen MSBuild EmccMaximumHeapSize. Standardvärdet är 2 147 483 648 byte, vilket kan vara för stort och leda till att appen kraschar om appen försöker allokera mer minne eftersom webbläsaren inte kan bevilja det. I följande exempel anges värdet till 268 435 456 byte i filen Program:

<EmccMaximumHeapSize>268435456</EmccMaximumHeapSize>

Mer information om egenskaper och mål för Mono/WebAssembly MSBuild finns i WasmApp.Common.targets (dotnet/runtime GitHub-lagringsplats).

Webcil-paketeringsformat för .NET-sammansättningar

Webcil är ett användarvänligt paketeringsformat för .NET-sammansättningar som är utformade för att aktivera användning av Blazor WebAssembly i restriktiva nätverksmiljöer. Webcil-filer använder en Standard WebAssembly-omslutning, där sammansättningarna distribueras som WebAssembly-filer som använder standardfilnamnstillägget .wasm.

Webcil är standardpaketeringsformatet när du publicerar en Blazor WebAssembly app. Om du vill inaktivera användningen av Webcil anger du följande MSBuild-egenskap i appens projektfil:

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

Anpassa hur startresurser läses in

Anpassa hur startresurser läses in med hjälp av api:et loadBootResource. Mer information finns i ASP.NET Core Blazor start.

Komprimering

När en Blazor WebAssembly-app publiceras komprimeras utdata statiskt i samband med publiceringen för att minska appens storlek och ta bort belastningen för körningskomprimering. Följande komprimeringsalgoritmer används:

• Brotli (högsta nivån)
• Gzip

Blazor förlitar sig på värden för att tillhandahålla de rätta komprimerade filerna. När du är värd för en Blazor WebAssembly fristående app kan ytterligare arbete krävas för att säkerställa att statiskt komprimerade filer hanteras:

• För konfiguration av IIS-web.config komprimering, se avsnittet IIS: Brotli och Gzip-komprimering.
• När du är värd för statiska värdlösningar som inte stöder statiskt komprimerad filinnehållsförhandling bör du överväga att konfigurera appen för att hämta och avkoda Brotli-komprimerade filer:

Hämta JavaScript Brotli-avkodaren från google/brotli GitHub-lagringsplatsen. Den minifierade avkodarfilen heter decode.min.js och finns i lagringsplatsens js mapp.

Not

Om den minifierade versionen av decode.js-skriptet (decode.min.js) misslyckas kan du prova att använda den oförminserade versionen (decode.js) i stället.

Uppdatera appen så att den använder avkodaren.

I filen wwwroot/index.html anger du autostart till false på taggen Blazor<script>:

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

Efter Blazortaggen <script> och före den avslutande </body> taggen lägger du till följande JavaScript-kodblock <script>. Följande funktion anropar fetch med cache: 'no-cache' för att hålla webbläsarens cache uppdaterad.

Blazor Web App:

<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>

Fristående Blazor WebAssembly:

<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>

Mer information om hur du läser in startresurser finns i ASP.NET Core Blazor start.

Om du vill inaktivera komprimering lägger du till egenskapen CompressionEnabled MSBuild i appens projektfil och anger värdet till false:

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

Egenskapen CompressionEnabled kan skickas till kommandot dotnet publish med följande syntax i ett kommandogränssnitt:

dotnet publish -p:CompressionEnabled=false

Skriv om URL:er för korrekt routning

Routingen för sidkomponenter i en Blazor WebAssembly-app är inte lika enkelt som routing av begäranden i en Blazor Server-app. Överväg en Blazor WebAssembly app med två komponenter:

• Main.razor: Laddas vid appens rot och innehåller en länk till komponenten About (href="About").
• About.razor: About komponent.

När appens standarddokument begärs med webbläsarens adressfält (till exempel https://www.contoso.com/):

1. Webbläsaren gör en begäran.
2. Standardsidan returneras, vilket vanligtvis är index.html.
3. index.html initierar appen.
4. Router-komponenten laddas och Razor-Main-komponenten återges.

På huvudsidan fungerar det att välja länken till komponenten About på klientsidan eftersom routern Blazor hindrar webbläsaren från att göra en begäran på Internet till www.contoso.com för About och tillhandahåller den renderade About-komponenten själv. Alla begäranden om interna slutpunkter i Blazor WebAssembly app fungerar på samma sätt: Begäranden utlöser inte webbläsarbaserade begäranden till serverbaserade resurser på Internet. Routern hanterar begäranden internt.

Om en begäran görs med webbläsarens adressfält för www.contoso.com/Aboutmisslyckas begäran. Det finns ingen sådan resurs på appens Internetvärd, så ett 404 – Hittades inte svar returneras.

Eftersom webbläsare gör begäranden till Internetbaserade värdar för sidor på klientsidan måste webbservrar och värdtjänster skriva om alla begäranden om resurser som inte fysiskt finns på servern till sidan index.html. När index.html returneras tar appens Blazor router över och svarar med rätt resurs.

När du distribuerar till en IIS-server kan du använda URL-omskrivningsmodulen med appens publicerade web.config fil. Mer information finns i avsnittet IIS.

Fristående distribution

En fristående distribution hanterar Blazor WebAssembly-appen som en uppsättning statiska filer som begärs direkt av klienter. Alla statiska filservrar kan hantera Blazor-appen.

Fristående distributionsfiler publiceras i antingen mappen /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot eller bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish\ (beroende på vilken version av .NET SDK som används), där platshållaren {TARGET FRAMEWORK} är målramverket.

Azure App Service

Blazor WebAssembly appar kan distribueras till Azure App Services på Windows, som värdar appen på IIS.

Distribution av en fristående Blazor WebAssembly app till Azure App Service för Linux stöds inte för närvarande. Vi rekommenderar att hosta en fristående Blazor WebAssembly-app med Azure Static Web Appssom stöder det här scenariot.

Azure Static Web Apps (statiska webbappar)

Använd någon av följande metoder för att distribuera en Blazor WebAssembly app till Azure Static Web Apps:

• Distribuera från Visual Studio
• Distribuera från Visual Studio Code
• Distribuera från GitHub

Distribuera från Visual Studio

Om du vill distribuera från Visual Studio skapar du en publiceringsprofil för Azure Static Web Apps:

1. Spara allt arbete som inte har sparats i projektet eftersom en Visual Studio-omstart kan krävas under processen.

2. I Visual Studio Publicera-gränssnittet väljer du MålAzureSpecifikt målAzure Static Web Apps för att skapa en publiceringsprofil.

3. Om Azure WebJobs Tools komponenten för Visual Studio inte är installerad visas en uppmaning om att installera komponenten ASP.NET och webbutveckling. Följ anvisningarna för att installera verktygen med Visual Studio Installer. Visual Studio stängs och öppnas automatiskt när verktygen installeras. När verktygen har installerats börjar du med det första steget för att skapa publiceringsprofilen.

4. I konfigurationen för publiceringsprofil anger du Prenumerationsnamn. Välj en befintlig instans eller välj Skapa en ny instans. När du skapar en ny instans i Azure-portalens användargränssnitt Skapa statiska webbappar anger du Distributionsinformation>Source till Other. Vänta tills distributionen har slutförts i Azure-portalen innan du fortsätter.

5. I publiceringsprofilkonfigurationen väljer du Azure Static Web Apps-instansen från instansens resursgrupp. Välj Slutför för att skapa publiceringsprofilen. Om Visual Studio uppmanar till att installera Static Web Apps (SWA) CLI installerar du CLI genom att följa anvisningarna. SWA CLI kräver NPM/Node.js (Visual Studio-dokumentation).

När publiceringsprofilen har skapats distribuerar du appen till Azure Static Web Apps-instansen med publiceringsprofilen genom att välja knappen Publicera.

Distribuera från Visual Studio Code

Information om hur du distribuerar från Visual Studio Code finns i Snabbstart: Skapa din första statiska webbplats med Azure Static Web Apps.

Distribuera från GitHub

Information om hur du distribuerar från en GitHub-lagringsplats finns i Självstudie: Skapa en statisk webbapp med Blazor i Azure Static Web Apps.

IIS

IIS är en kompatibel statisk filserver för Blazor appar. Information om hur du konfigurerar IIS som värd för Blazorfinns i Skapa en statisk webbplats på IIS-.

Publicerade tillgångar skapas i mappen /bin/Release/{TARGET FRAMEWORK}/publish eller bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish, beroende på vilken version av SDK som används och var {TARGET FRAMEWORK} platshållaren är målramverket. Lägg upp innehållet i mappen publish på webbservern eller värdtjänsten.

web.config

När ett Blazor projekt publiceras skapas en web.config fil med följande IIS-konfiguration:

• MIME-typer
• HTTP-komprimering är aktiverat för följande MIME-typer:
  • application/octet-stream
  • application/wasm
• Regler för URL-omskrivningsmodul upprättas:
  • Hantera den underkatalog där appens statiska tillgångar finns (wwwroot/{PATH REQUESTED}).
  • Skapa SPA-fallback-routning så att begäranden om icke-filresurser omdirigeras till appens standardfil i mappen för statiska resurser (wwwroot/index.html).

Använd en anpassad web.config

Så här använder du en anpassad web.config fil:

1. Placera den anpassade web.config filen i projektets rotmapp.
2. Publicera projektet. Mer information finns i Värd och distribuera ASP.NET Core Blazor.

Om SDK:ns web.config generering eller omvandling under publiceringen antingen inte flyttar filen till publicerade tillgångar i mappen publish eller ändrar den anpassade konfigurationen i din anpassade web.config-fil använder du någon av följande metoder efter behov för att ta fullständig kontroll över processen:

• Om SDK:t inte genererar filen, till exempel i en fristående Blazor WebAssembly app på /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot eller bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish, beroende på vilken version av SDK:t som används och var {TARGET FRAMEWORK} platshållaren är målramverket, anger du egenskapen <PublishIISAssets> till true i projektfilen (.csproj). Vanligtvis för fristående WebAssembly-appar är detta den enda obligatoriska inställningen för att flytta en anpassad web.config fil och förhindra att filen transformeras av SDK:t.

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

• Inaktivera web.config-transformationen för SDK:et i projektfilen (.csproj):

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

• Lägg till ett anpassat mål i projektfilen (.csproj) för att flytta en anpassad web.config fil. I följande exempel placeras den anpassade web.config-filen av utvecklaren i projektets rot. Om filen web.config finns någon annanstans anger du sökvägen till filen i SourceFiles. I följande exempel anges mappen publish med $(PublishDir), men anger en sökväg till DestinationFolder för en anpassad utdataplats.

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

Installera url-omskrivningsmodulen

URL Rewrite Module krävs för att skriva om URL:er. Modulen är inte installerad som standard och den är inte tillgänglig för installation som en rolltjänstfunktion för webbserver (IIS). Modulen måste laddas ned från IIS-webbplatsen. Använd installationsprogrammet för webbplattformen för att installera modulen:

1. Navigera lokalt till nedladdningssidan för URL-omskrivningsmodulen . För den engelska versionen väljer du WebPI- för att ladda ned WebPI-installationsprogrammet. För andra språk väljer du lämplig arkitektur för servern (x86/x64) för att ladda ned installationsprogrammet.
2. Kopiera installationsprogrammet till servern. Kör installationsprogrammet. Välj knappen Installera och godkänn licensvillkoren. En omstart av servern krävs inte när installationen är klar.

Konfigurera webbplatsen

Ange webbplatsens fysiska sökväg till appens mapp. Mappen innehåller:

• Den web.config fil som IIS använder för att konfigurera webbplatsen, inklusive nödvändiga omdirigeringsregler och filinnehållstyper.
• Appens statiska tillgångsmapp.

Värda som en IIS-underapp

Om en fristående app hanteras som en IIS-underapp utför du något av följande:

• Inaktivera den ärvda ASP.NET Core Module-hanteraren.

  Ta bort hanteraren i Blazor-appens publicerade web.config-fil genom att lägga till ett <handlers> avsnitt i avsnittet <system.webServer> i filen:

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

• Inaktivera arv av rotappens (moderappens) <system.webServer>-avsnitt med ett <location>-element där inheritInChildApplications är inställt på false:

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

  Obs

  Inaktivering av arv av rotappens <system.webServer>-avsnitt är standardkonfigurationen för publicerade appar med .NET SDK.

Att ta bort hanteraren eller inaktivera arv sker dessutom genom att konfigurera appens bassökväg. Ange appens bassökväg i appens index.html fil till det IIS-alias som används när du konfigurerar underappen i IIS.

Konfigurera appens baskatalog genom att följa anvisningarna i artikeln Host och distribuera ASP.NET Core Blazor.

Brotli- och Gzip-komprimering

Det här avsnittet gäller endast fristående Blazor WebAssembly appar.

IIS kan konfigureras via web.config för att hantera Brotli- eller Gzip-komprimerade Blazor tillgångar för fristående Blazor WebAssembly appar. Ett exempel på en konfigurationsfil finns i web.config.

Ytterligare konfiguration av exemplet web.config fil kan krävas i följande scenarier:

• Appens specifikation kräver något av följande:
  • Servera komprimerade filer som inte har konfigurerats av exempelfilen web.config.
  • Hantera komprimerade filer som konfigurerats av exemplet web.config fil i ett okomprimerat format.
• Serverns IIS-konfiguration (till exempel applicationHost.config) tillhandahåller IIS-standardvärden på servernivå. Beroende på konfigurationen på servernivå kan appen kräva en annan IIS-konfiguration än vad exemplet web.config fil innehåller.

Mer information om anpassade web.config filer finns i avsnittet Använd en anpassad web.config.

Felsökning

Om ett 500 – internt serverfel tas emot och IIS-hanteraren utlöser fel när du försöker komma åt webbplatsens konfiguration kontrollerar du att URL-omskrivningsmodulen är installerad. När modulen inte är installerad kan web.config-filen inte parsas av IIS. Detta hindrar IIS-hanteraren från att läsa in webbplatsens konfiguration och hindrar webbplatsen från att leverera Blazor:s statiska filer.

Mer information om hur du felsöker distributioner till IIS finns i Felsöka ASP.NET Core i Azure App Service och IIS.

Azure Storage

Azure Storage statisk filvärd tillåter serverlös Blazor appvärd. Anpassade domännamn, Azure Content Delivery Network (CDN) och HTTPS stöds.

När blobtjänsten är aktiverad för statisk webbplats som är värd för ett lagringskonto:

• Ange Index-dokumentnamnet till index.html.
• Ange dokumentsökvägen Fel till index.html. Razor komponenter och andra icke-filslutpunkter finns inte på fysiska sökvägar i det statiska innehåll som lagras av blobtjänsten. När en begäran om en av dessa resurser tas emot som Blazor-routern ska hantera, och ett 404 - Sidan kunde inte hittas-fel genereras av blobtjänsten, dirigeras begäran till felsökningsvägen. Den index.html bloben returneras och den Blazor routern läser in och bearbetar sökvägen.

Om filer inte läses in vid körning på grund av olämpliga MIME-typer i filernas Content-Type-huvuden, vidta någon av följande åtgärder:

• Konfigurera verktygen för att ange rätt MIME-typer (Content-Type rubriker) när filerna distribueras.

• Ändra MIME-typerna (Content-Type rubriker) för filerna när appen har distribuerats.

  I Storage Explorer (Azure Portal) för varje fil:

  1. Högerklicka på filen och välj Egenskaper.
  2. Ställ in ContentType och tryck på knappen Spara.

Mer information finns i static website hosting in Azure Storage.

Nginx

Följande nginx.conf fil är förenklad för att visa hur du konfigurerar Nginx för att skicka index.html-filen när den inte kan hitta en motsvarande fil på disken.

events { }
http {
    server {
        listen 80;

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

När du ställer in NGINX-hastighetsgräns med limit_reqkan Blazor WebAssembly appar kräva ett stort burst parametervärde för att hantera det relativt stora antalet begäranden som görs av en app. Ställ inledningsvis in värdet på minst 60:

http {
    server {
        ...

        location / {
            ...

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

Öka värdet om webbläsarutvecklarverktyg eller ett verktyg för nätverkstrafik anger att begäranden får en 503 – Tjänsten är inte tillgänglig statuskod.

Mer information om Nginx-webbserverkonfiguration för produktion finns i Skapa NGINX Plus- och NGINX-konfigurationsfiler.

Apache

Så här distribuerar du en Blazor WebAssembly app till Apache:

1. Skapa Apache-konfigurationsfilen. Följande exempel är en förenklad konfigurationsfil (blazorapp.config):

   <VirtualHost *:80>
       ServerName www.example.com
       ServerAlias *.example.com
   
       DocumentRoot "/var/www/blazorapp"
       ErrorDocument 404 /index.html
   
       AddType application/wasm .wasm
   
       <Directory "/var/www/blazorapp">
           Options -Indexes
           AllowOverride None
       </Directory>
   
       <IfModule mod_deflate.c>
           AddOutputFilterByType DEFLATE text/css
           AddOutputFilterByType DEFLATE application/javascript
           AddOutputFilterByType DEFLATE text/html
           AddOutputFilterByType DEFLATE application/octet-stream
           AddOutputFilterByType DEFLATE application/wasm
           <IfModule mod_setenvif.c>
               BrowserMatch ^Mozilla/4 gzip-only-text/html
               BrowserMatch ^Mozilla/4.0[678] no-gzip
               BrowserMatch bMSIE !no-gzip !gzip-only-text/html
           </IfModule>
       </IfModule>
   
       ErrorLog /var/log/httpd/blazorapp-error.log
       CustomLog /var/log/httpd/blazorapp-access.log common
   </VirtualHost>
   

1. Placera Apache-konfigurationsfilen i katalogen /etc/httpd/conf.d/.

2. Placera appens publicerade resurser (/bin/Release/{TARGET FRAMEWORK}/publish/wwwroot, med platshållaren {TARGET FRAMEWORK} som målramverket) i katalogen /var/www/blazorapp (platsen som har specificerats för DocumentRoot i konfigurationsfilen).

3. Starta om Apache-tjänsten.

Mer information finns i mod_mime och mod_deflate.

GitHub-sidor

GitHub-standardåtgärden, som distribuerar sidor, hoppar över distributionen av mappar som börjar med understreck, till exempel mappen _framework. Om du vill distribuera mappar som börjar med understreck lägger du till en tom .nojekyll fil i Git-grenen.

Git behandlar JavaScript-filer (JS), till exempel blazor.webassembly.js, som text och konverterar radslut från CRLF (vagnreturlinjeflöde) till LF (radflöde) i distributionskedjan. Dessa ändringar i JS filer ger andra filhashvärden än Blazor skickar till klienten i blazor.boot.json-filen. Felmatchningarna resulterar i integritetskontrollfel på klienten. En metod för att lösa det här problemet är att lägga till .gitattributes-filen med *.js binary-raden innan appens resurser läggs till i Git-grenen. Raden *.js binary konfigurerar Git för att behandla JS filer som binära filer, vilket undviker bearbetning av filerna i distributionspipelinen. Fil-hashvärdena för de obearbetade filerna överensstämmer med posterna i blazor.boot.json-filen, och integritetskontrollerna på klientsidan godkänns. Mer information finns i ASP.NET Core Blazor WebAssembly .NET Runtime och cachelagring av apppaket.

Om du vill hantera URL-omskrivningar lägger du till en wwwroot/404.html fil med ett skript som hanterar omdirigering av begäran till sidan index.html. Ett exempel finns i SteveSandersonMS/BlazorOnGitHubPages GitHub-lagringsplats:

• wwwroot/404.html
• Live-webbplats

När du använder en projektwebbplats i stället för en organisationswebbplats uppdaterar du taggen <base> i wwwroot/index.html. Ange värdet för href attribut till GitHub-lagringsplatsens namn med ett avslutande snedstreck (till exempel /my-repository/). I SteveSandersonMS/BlazorOnGitHubPages GitHub-lagringsplatsuppdateras bas-href vid publicering av .github/workflows/main.yml-konfigurationsfilen.

Not

SteveSandersonMS/BlazorOnGitHubPages GitHub-lagringsplats inte ägs, underhålls eller stöds av .NET Foundation eller Microsoft.

Fristående med Docker

En fristående Blazor WebAssembly app publiceras som en uppsättning statiska filer för värdhantering av en statisk filserver.

För att köra appen i Docker:

• Välj en Docker-container med webbserverstöd, till exempel Ngnix eller Apache.
• Kopiera publish mapptillgångar till en platsmapp som definierats på webbservern för hantering av statiska filer.
• Använd ytterligare konfiguration efter behov för att hantera Blazor WebAssembly-appen.

Konfigurationsvägledning finns i följande resurser:

• Nginx-avsnittet eller Apache-avsnittet i den här artikeln
• Docker-dokumentation

Värdkonfigurationsvärden

Blazor WebAssembly applikationer kan acceptera följande hostvärdens konfigurationsvärden som kommandoradsargument under körning i utvecklingsmiljön.

Innehållsrot

Argumentet --contentroot anger den absoluta sökvägen till katalogen som innehåller appens innehållsfiler (innehållsroten). I följande exempel är /content-root-path rotvägen för appens innehåll.

• Ange argumentet när du kör appen lokalt i kommandotolken. Från appens katalog kör du:

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

• Lägg till en post i launchSettings.json-filen för appen i IIS Express-profilen . Den här inställningen används när appen körs med Visual Studio-felsökningsprogrammet och från en kommandotolk med dotnet watch (eller dotnet run).

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

• I Visual Studio anger du argumentet i Egenskaper>Felsökning>Applikationsargument. Om du anger argumentet på egenskapssidan för Visual Studio läggs argumentet till i filen launchSettings.json.

  --contentroot=/content-root-path
  

Sökvägsbas

Argumentet --pathbase anger appbassökvägen för en app som körs lokalt med en relativ URL-sökväg som inte är rot (taggen <base>href är inställd på en annan sökväg än / för mellanlagring och produktion). I följande exempel är /relative-URL-path appens sökvägsbas. För mer information, se applikationens basväg.

Viktig

Till skillnad från sökvägen till href av <base>-taggen, ta inte med ett bakre snedstreck (/) när du skickar argumentvärdet för --pathbase. Om appbassökvägen anges i taggen <base> som <base href="/CoolApp/"> (innehåller ett avslutande snedstreck) skickar du kommandoradsargumentvärdet som --pathbase=/CoolApp (inget avslutande snedstreck).

• Ange argumentet när du kör appen lokalt i en kommandotolk. Från appens katalog kör du:

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

• Lägg till en post i programmets launchSettings.json-fil inom profilen IIS Express. Den här inställningen används när du kör appen med Visual Studio-felsökningsprogrammet och från en kommandotolk med dotnet watch (eller dotnet run).

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

• I Visual Studio specificerar du argumentet i Egenskaper>Felsökning>Applikationsargument. Om du anger argumentet på egenskapssidan för Visual Studio läggs argumentet till i filen launchSettings.json.

  --pathbase=/relative-URL-path
  

URL:er

Argumentet --urls anger IP-adresser eller värdadresser med portar och protokoll för att lyssna efter begäranden.

• Skicka argumentet när du kör appen lokalt i en kommandoprompt. Från appens katalog kör du:

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

• Lägg till en post i launchSettings.json-filen i appens -profil för IIS Express. Den här inställningen används när du kör appen med Visual Studio-felsökningsprogrammet och från en kommandotolk med dotnet watch (eller dotnet run).

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

• I Visual Studio anger du argumentet i Egenskaper>Felsökning>Programargument. Om du anger argumentet på egenskapssidan för Visual Studio läggs argumentet till i filen launchSettings.json.

  --urls=http://127.0.0.1:0
  

Konfigurera trimmern

Blazor utför IL-trimning (Intermediate Language) på varje releasebygge för att ta bort onödiga IL från utdataassemblyna. Mer information finns i Konfigurera Trimmer för ASP.NET Core Blazor.

Ändra filnamnstillägget för DLL-filer

Det här avsnittet gäller för ASP.NET Core 6.x och 7.x. I ASP.NET Core i .NET 8 eller senare distribueras .NET-sammansättningar som WebAssembly-filer (.wasm) med hjälp av filformatet Webcil. I ASP.NET Core i .NET 8 eller senare gäller det här avsnittet endast om filformatet webcil har inaktiverats i appens projektfil.

Om en brandvägg, antivirusprogram eller nätverkssäkerhetsinstallation blockerar överföringen av appens DLL-filer (Dynamic Link Library) (.dll) kan du följa anvisningarna i det här avsnittet för att ändra filnamnstilläggen för appens publicerade DLL-filer.

Not

Att ändra filnamnstilläggen för appens DLL-filer kanske inte löser problemet eftersom många säkerhetssystem söker igenom innehållet i appens filer, inte bara kontrollerar filnamnstillägg.

Om du vill ha en mer robust metod i miljöer som blockerar nedladdning och körning av DLL-filer använder du ASP.NET Core i .NET 8 eller senare, som paketerar .NET-sammansättningar som WebAssembly-filer (.wasm) med hjälp av Webcil- filformat. För mer information, se avsnittet Webcil-paketeringsformat för .NET-sammansättningar i en version 8.0 eller senare av den här artikeln.

Det finns metoder från tredje part för att hantera detta problem. Mer information finns i resurserna på Awesome Blazor.

När du har publicerat appen använder du ett gränssnittsskript eller en DevOps-byggpipeline för att byta namn på .dll filer för att använda ett annat filnamnstillägg i katalogen för appens publicerade utdata.

I följande exempel:

• PowerShell (PS) används för att uppdatera filnamnstilläggen.
• .dll filer har bytt namn för att använda filnamnstillägget .bin från kommandoraden.
• Filer som anges i den publicerade blazor.boot.json-filen med ett .dll filnamnstillägg uppdateras till filnamnstillägget .bin.
• Om också service worker-tillgångar används uppdaterar ett PowerShell-kommando de .dll-filer som anges i service-worker-assets.js-filen till filnamnstillägget .bin.

Om du vill använda ett annat filnamnstillägg än .binersätter du .bin i följande kommandon med önskat filnamnstillägg.

På Windows:

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

I föregående kommando är platshållaren {PATH} sökvägen till den publicerade mappen _framework (till exempel .\bin\Release\net6.0\browser-wasm\publish\wwwroot\_framework från projektets rotmapp).

Om service worker-resurser också används:

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

I föregående kommando är platshållaren {PATH} sökvägen till den publicerade service-worker-assets.js-filen.

I Linux eller macOS:

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

I föregående kommando är platshållaren {PATH} sökvägen till den publicerade mappen _framework (till exempel .\bin\Release\net6.0\browser-wasm\publish\wwwroot\_framework från projektets rotmapp).

Om service worker-tillgångar också används:

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

I föregående kommando är platshållaren {PATH} sökvägen till den publicerade service-worker-assets.js-filen.

Använd någon av följande metoder för att hantera komprimerade blazor.boot.json.gz- och blazor.boot.json.br-filer:

• Ta bort de komprimerade blazor.boot.json.gz- och blazor.boot.json.br-filerna. Komprimering är inaktiverat med den här metoden.
• Återkomprimera den uppdaterade blazor.boot.json-filen.

Föregående vägledning för den komprimerade blazor.boot.json-filen gäller även när service worker-resurser används. Ta bort eller komprimera service-worker-assets.js.br och service-worker-assets.js.gz. Annars misslyckas filintegritetskontroller i webbläsaren.

I följande Windows-exempel för .NET 6 används ett PowerShell-skript som placeras i projektets rot. Följande skript, som inaktiverar komprimering, är grunden för ytterligare ändringar om du vill återkomprimera blazor.boot.json-filen.

ChangeDLLExtensions.ps1::

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

Om service worker-tillgångar också används lägger du till följande kommandon:

((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

I projektfilen körs skriptet när appen har publicerats för Release-konfigurationen:

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

Notera

När du byter namn på och använder fördröjd inläsning av samma komponenter, se anvisningarna i Fördröjd inläsning av komponenter i ASP.NET Core Blazor WebAssembly.

Vanligtvis kräver appens server konfiguration av statiska tillgångar för att hantera filerna med det uppdaterade tillägget. För en app som hanteras av IIS lägger du till en MIME-mappningspost (<mimeMap>) för det nya filtillägget i avsnittet statiskt innehåll (<staticContent>) i en anpassad web.config fil. I följande exempel förutsätts att filnamnstillägget ändras från .dll till .bin:

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

Inkludera en uppdatering för komprimerade filer om komprimering används:

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

Ta bort posten för filnamnstillägget .dll:

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

Ta bort poster för komprimerade .dll filer om komprimering används:

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

Mer information om anpassade web.config filer finns i avsnittet Använd en anpassad web.config.

Tidigare datakorruption

Vanligtvis vid utplacering:

• Endast de filer som har ändrats ersätts, vilket vanligtvis resulterar i en snabbare distribution.
• Befintliga filer som inte ingår i den nya distributionen finns kvar för användning av den nya distributionen.

I sällsynta fall kan kvardröjande filer från en tidigare distribution skada en ny distribution. Att ta bort den befintliga distributionen (eller den lokalt publicerade appen före distributionen) kan lösa problemet med en skadad distribution. Att ta bort den befintliga distributionen när räcker ofta för att lösa problemet, bland annat för en DevOps-bygg- och distributionspipeline.

Om du fastställer att det alltid krävs att rensa en tidigare distribution när en DevOps-bygg- och distributionspipeline används kan du tillfälligt lägga till ett steg i bygg-pipelinen för att ta bort den tidigare distributionen för varje ny distribution tills du felsöker den exakta orsaken till skadan.

Lösa integritetskontrollfel

När Blazor WebAssembly laddar ned en apps startfiler instrueras webbläsaren att utföra integritetskontroller av svaren. Blazor skickar SHA-256-hashvärden för DLL (.dll), WebAssembly (.wasm) och andra filer i den blazor.boot.json filen, som inte cachelagras på klienter. Fil-hashvärden för cachelagrade filer jämförs med hashvärdena i blazor.boot.json-filen. För cachelagrade filer med matchande hash använder Blazor de cachelagrade filerna. Annars begärs filer från servern. När en fil har laddats ned kontrolleras dess hash igen för integritetsverifiering. Ett fel genereras av webbläsaren om någon nedladdad fils integritetskontroll misslyckas.

Blazoralgoritm för hantering av filintegritet:

• Säkerställer att appen inte riskerar att läsa in en inkonsekvent uppsättning filer, till exempel om en ny distribution tillämpas på webbservern medan användaren håller på att ladda ned programfilerna. Inkonsekventa filer kan resultera i en felaktig app.
• Säkerställer att användarens webbläsare aldrig cachelagrar inkonsekventa eller ogiltiga svar, vilket kan hindra appen från att starta även om användaren uppdaterar sidan manuellt.
• Gör det säkert att cacha svaren och inte kontrollera ändringar på serversidan tills de förväntade SHA-256-hashvärdena ändras, så att efterföljande sidinläsningar innebär färre begäranden och utförs snabbare.

Om webbservern returnerar svar som inte matchar de förväntade SHA-256-hashvärdena visas ett fel som liknar följande exempel i webbläsarens utvecklarkonsol:

Det gick inte att hitta en giltig sammanfattning i attributet "integritet" för resursenhttps://myapp.example.com/_framework/MyBlazorApp.dllmed den beräknade SHA-256-integriteten "IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY=". Resursen har blockerats.

I de flesta fall indikerar varningen inte något problem med integritetskontroll. I stället innebär varningen vanligtvis att det finns något annat problem.

Information om Blazor WebAssemblystartreferenskälla finns i filen Boot.WebAssembly.ts i dotnet/aspnetcore GitHub-lagringsplatsen.

Anteckning

Dokumentationslänkar till .NET-referenskällan läser vanligtvis in lagringsplatsens standardgren, vilket representerar den aktuella utvecklingen för nästa version av .NET. Om du vill välja en tagg för en specifik version använder du listrutan Välj bland grenar eller taggar. Mer information finns i Så här väljer du en versionstagg för ASP.NET Core-källkod (dotnet/AspNetCore.Docs #26205).

Diagnostisera integritetsproblem

När en app skapas beskriver det genererade blazor.boot.json-manifestet SHA-256-hashvärden för startresurser när byggresultatet skapas. Integritetskontrollen godkänns så länge SHA-256-hashvärden i blazor.boot.json matchar filerna som levereras till webbläsaren.

Vanliga orsaker till att detta misslyckas är:

• Webbserverns svar är ett fel (till exempel ett 404 – Hittades inte eller en 500 – Internt serverfel) i stället för den fil som webbläsaren begärde. Detta rapporteras av webbläsaren som ett integritetskontrollfel och inte som ett svarsfel.
• Något har ändrat innehållet i filerna mellan versionen och leveransen av filerna till webbläsaren. Detta kan inträffa:
  • Om du eller byggverktygen ändrar build-utdata manuellt.
  • Om någon aspekt av distributionsprocessen ändrade filerna. Om du till exempel använder en Git-baserad distributionsmekanism bör du tänka på att Git transparent konverterar radslut i Windows-stil till Unix-stil om du checkar in filer i Windows och checkar ut dem på Linux. Om du ändrar filradsslut ändras SHA-256-hashvärdena. Undvik det här problemet genom att använda .gitattributes för att behandla byggartefakter som binary filer.
  • Webbservern ändrar filinnehållet som en del av att betjäna dem. Vissa innehållsdistributionsnätverk (CDN) försöker till exempel automatiskt minimera HTML och därmed ändra det. Du kan behöva inaktivera sådana funktioner.
• Den blazor.boot.json filen kan inte läsas in korrekt eller cachelagras felaktigt på klienten. Vanliga orsaker är något av följande:
  • Felkonfigurerad eller trasig anpassad utvecklingskod.
  • Ett eller flera felkonfigurerade mellanliggande cachelagringslager.

Så här diagnostiserar du vilka av dessa som gäller i ditt fall:

1. Observera vilken fil som utlöser felet genom att läsa felmeddelandet.
2. Öppna webbläsarens utvecklarverktyg och titta på fliken Network. Om det behövs läser du in sidan igen för att se listan över begäranden och svar. Leta reda på filen som utlöser felet i listan.
3. Kontrollera HTTP-statuskoden i svaret. Om servern returnerar något annat än 200 – OK (eller en annan 2xx-statuskod) har du ett problem på serversidan att diagnostisera. Statuskod 403 innebär till exempel att det finns ett auktoriseringsproblem, medan statuskod 500 innebär att servern misslyckas på ett ospecificerat sätt. Läs loggarna på serversidan för att diagnostisera och åtgärda appen.
4. Om statuskoden är 200 – OK för resursen kan du titta på svarsinnehållet i webbläsarens utvecklarverktyg och kontrollera att innehållet matchar förväntade data. Ett vanligt problem är till exempel att felkonfigurera routning så att begäranden returnerar dina index.html data även för andra filer. Kontrollera att svar på .wasm begäranden är WebAssembly-binärfiler och att svar på .dll begäranden är .NET-sammansättningsbinärfiler. Annars har du ett problem med ruttning på serversidan som behöver diagnostiseras.
5. Försök att verifiera appens publicerade och distribuerade utdata med Felsöknings-integritet PowerShell-skriptet.

Om du bekräftar att servern returnerar rimligen korrekta data måste det finnas något annat som ändrar innehållet mellan bygget och leveransen av filen. Så här undersöker du detta:

• Granska byggverktygskedjan och distributionsmekanismen om de ändrar filer när filerna har skapats. Ett exempel på detta är när Git omvandlar filradsslut, enligt beskrivningen tidigare.
• Granska webbservern eller CDN-konfigurationen om de har konfigurerats för att ändra svar dynamiskt (till exempel försöker minimera HTML). Det är bra att webbservern implementerar HTTP-komprimering (till exempel returnerar content-encoding: br eller content-encoding: gzip), eftersom detta inte påverkar resultatet efter dekomprimering. Det är dock inte okej för webbservern att ändra okomprimerade data.

Felsöka PowerShell-skript för integritetssäkring

Använd powershell-skriptet integrity.ps1 för att verifiera en publicerad och distribuerad Blazor app. Skriptet tillhandahålls för PowerShell Core 7 eller senare som en startpunkt när appen har integritetsproblem som Blazor ramverket inte kan identifiera. Anpassning av skriptet kan krävas för dina appar, inklusive om det körs på version av PowerShell senare än version 7.2.0.

Skriptet kontrollerar filerna i mappen publish och de som har laddats ned från den distribuerade appen för att identifiera problem i de olika manifesten som innehåller integritetskontrollsummor. Dessa kontroller bör identifiera de vanligaste problemen:

• Du har ändrat en fil i de publicerade utdata utan att inse det.
• Appen distribuerades inte korrekt till distributionsmålet, eller så ändrades något i distributionsmålets miljö.
• Det finns skillnader mellan den distribuerade appen och utdata från publiceringen av appen.

Anropa skriptet med följande kommando i ett PowerShell-kommandogränssnitt:

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

I följande exempel körs skriptet på en app som körs lokalt på https://localhost:5001/:

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

Platshållare:

• {BASE URL}: URL:en för den distribuerade appen. Ett avslutande snedstreck (/) krävs.
• {PUBLISH OUTPUT FOLDER}: Sökvägen till appens publish mapp eller plats där appen publiceras för distribution.

Notis

När du klonar dotnet/AspNetCore.Docs GitHub-lagringsplatsen kan integrity.ps1-skriptet placeras i karantän av Bitdefender eller någon annan virusskanner som finns i systemet. Vanligtvis fångas filen av en virusskanners heuristisk genomsökning teknik, som bara letar efter mönster i filer som kan indikera förekomsten av skadlig kod. Om du vill förhindra att virusskannern quarantiar filen lägger du till ett undantag till virusskannern innan du klonar lagringsplatsen. Följande exempel är en typisk sökväg till skriptet i ett Windows-system. Justera sökvägen efter behov för andra system. Platshållaren {USER} är användarens sökvägssegment.

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

Varning: Att skapa undantag för virusskanner är farligt och bör endast utföras när du är säker på att filen är säker.

Att jämföra kontrollsumman för en fil med en giltig kontrollsumma garanterar inte filsäkerheten, men att ändra en fil på ett sätt som upprätthåller en kontrollsumma är inte trivialt för skadliga användare. Därför är kontrollsummor användbara som en generell säkerhetsmetod. Jämför kontrollsumman för den lokala integrity.ps1-filen med något av följande värden:

• SHA256: 32c24cb667d79a701135cb72f6bae490d81703323f61b8af2c7e5e5dc0f0c2bb
• MD5: 9cee7d7ec86ee809a329b5406fbf21a8

Hämta filens kontrollsumma i Windows OS med följande kommando. Ange sökvägen och filnamnet för platshållaren för {PATH AND FILE NAME} och ange vilken typ av kontrollsumma som ska skapas för platshållaren för {SHA512|MD5}, antingen SHA256 eller MD5:

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

Om du har anledning till oro för att verifieringen av kontrollsumman inte är tillräckligt säker i din miljö kan du kontakta organisationens säkerhetsledare för att få vägledning.

Mer information finns i Översikt över skydd mot hot av Microsoft Defender Antivirus.

Inaktivera integritetskontroll för icke-PWA-appar

I de flesta fall ska du inte inaktivera integritetskontroll. Inaktivering av integritetskontroll löser inte det underliggande problemet som har orsakat oväntade svar och resulterar i att de fördelar som anges tidigare går förlorade.

Det kan finnas fall där webbservern inte kan förlita sig på att returnera konsekventa svar och du inte har något annat val än att tillfälligt inaktivera integritetskontroller tills det underliggande problemet har lösts.

Om du vill inaktivera integritetskontroller lägger du till följande i en egenskapsgrupp i Blazor WebAssembly-appens projektfil (.csproj):

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResources inaktiverar också Blazorstandardbeteende för cachelagring av .dll, .wasmoch andra filer baserat på deras SHA-256-hashar eftersom egenskapen anger att SHA-256-hashvärdena inte kan förlita sig på korrekthet. Även med den här inställningen kan webbläsarens normala HTTP-cache fortfarande lagra dessa filer, men om detta händer beror på din webbserverkonfiguration och de cache-control headers som den hanterar.

Notera

Egenskapen BlazorCacheBootResources inaktiverar inte integritetskontroller för progressiva webbapplikationer (PWA:er). Vägledning om PWA finns i avsnittet Inaktivera integritetskontroll för PWA:er.

Vi kan inte ange en fullständig lista över scenarier där inaktivering av integritetskontroll krävs. Servrar kan besvara en begäran på godtyckliga sätt utanför omfånget för det Blazor ramverket. Ramverket tillhandahåller inställningen BlazorCacheBootResources för att göra appen körbar på bekostnad av att förlorar den integritetsgaranti som appen kan ge. Återigen rekommenderar vi inte att du inaktiverar integritetskontroll, särskilt inte för produktionsdistributioner. Utvecklare bör försöka lösa det underliggande integritetsproblem som gör att integritetskontroll misslyckas.

Några allmänna fall som kan orsaka integritetsproblem är:

• Körs på HTTP där integritet inte kan kontrolleras.
• Om distributionsprocessen ändrar filerna efter publiceringen på något sätt.
• Om värden ändrar filerna på något sätt.

Inaktivera integritetskontroll för PWA:er

BlazorPWA-mall (Progressive Web Application) innehåller en föreslagen service-worker.published.js fil som ansvarar för att hämta och lagra programfiler för offlineanvändning. Det här är en separat process från den normala appstartmekanismen och har en egen separat logik för integritetskontroll.

I filen service-worker.published.js finns följande rad:

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

Om du vill inaktivera integritetskontroll tar du bort parametern integrity genom att ändra raden till följande:

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

Återigen innebär inaktivering av integritetskontroll att du förlorar de säkerhetsgarantier som erbjuds av integritetskontroll. Det finns till exempel en risk att om användarens webbläsare cachelagrar appen exakt när du distribuerar en ny version kan den cachelagra vissa filer från den gamla distributionen och vissa från den nya distributionen. Om det händer fastnar appen i ett trasigt tillstånd tills du distribuerar ytterligare en uppdatering.