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

Den här artikeln beskriver hur du hostar och driftsätter Blazor WebAssembly-appar.

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 och andra artiklar i den här noden för IIS, Azure-tjänster, Apache, Nginx och GitHub Pages.

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) för att appen ska vara värd i en underdomän.

IIS-underprogram för värdskap kräver att du anger appens basvä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.

Anmärkning

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 Värd och distribuera ASP.NET Core Blazor WebAssembly med IIS.

Fristående utplacering

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 distributionstillgångar publiceras i antingen /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot-mappen eller bin/Release/{TARGET FRAMEWORK}/browser-wasm/publish-mappen, där {TARGET FRAMEWORK} är platshållaren för målramverket.

Azure App Service

Blazor WebAssembly appar kan distribueras till Azure App Services i Windows, som är värd för 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.

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 Nginx 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- eller Apache-artiklar
• Docker-dokumentation

Värdkonfigurationsvärden

Blazor WebAssembly applikationer kan acceptera följande värdkonfigurationsvärden som kommandoradsargument vid körtid i utvecklingsmiljö.

Rot för innehåll

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 basvägen för ASP.NET Core-app Blazor.

Viktigt!

Till skillnad från sökvägen som tillhandahålls till href via <base>-taggen, ta inte med ett snedstreck på slutet (/) när du anger 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 kommandotolken. Från appens katalog kör du:

  dotnet watch --pathbase=/relative-URL-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 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 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.

  --pathbase=/relative-URL-path
  

För mer information, se basvägen för ASP.NET Core-app Blazor.

URLer

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

• Ange argumentet när du kör appen lokalt i kommandotolken. 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 för appen i IIS Express-profilen. 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>Applikationsargument. 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.

Tidigare driftsättning korruption

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 en gång 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.