Hostování a nasazení aplikací ASP.NET Core Blazor WebAssembly

Tento článek vysvětluje, jak hostovat a nasazovat aplikace Blazor WebAssembly.

S modelem Blazor WebAssemblyhostování:

• Aplikace Blazor , její závislosti a modul runtime .NET se stáhnou paralelně do prohlížeče.
• Aplikace se spustí přímo ve vlákně uživatelského rozhraní prohlížeče.

Tento článek se týká scénáře nasazení, ve kterém Blazor je aplikace umístěná na statickém hostitelském webovém serveru nebo službě, .NET se nepoužívá k poskytování Blazor aplikace. Tato strategie je popsána v části Samostatné nasazení a dalších článcích v tomto uzlu pro službu IIS, služby Azure, Apache, Nginx a GitHub Pages.

Subdoména a hostování sub-aplikace IIS

Hostování subdomény nevyžaduje zvláštní konfiguraci aplikace. Pro hostování aplikace v subdoméně nemusíte konfigurovat základní cestu aplikace (značka ve ).

Hostování dílčích aplikací služby IIS vyžaduje , abyste nastavili základní cestu aplikace. Další informace a křížové odkazy na další pokyny k hostování dílčích aplikací služby IIS naleznete v tématu Hostitel a nasazení ASP.NET Core Blazor.

Zmenšení maximální velikosti haldy u některých prohlížečů mobilních zařízení

Při budování Blazor aplikace, která běží na klientském zařízení (.Client projektu Blazor Web App nebo samostatné Blazor WebAssembly aplikace) a je zaměřena na prohlížeče mobilních zařízení, zejména Safari v systému iOS, je nutné snížit maximální paměť aplikace pomocí vlastnosti EmccMaximumHeapSize MSBuild. Výchozí hodnota je 2 147 483 648 bajtů, což může být příliš velký objem a aplikace může selhat, pokud se pokusí přidělit více paměti, kterou prohlížeč neposkytne. Následující příklad nastaví hodnotu na 268 435 456 bajtů v Program souboru:

<EmccMaximumHeapSize>268435456</EmccMaximumHeapSize>

Další informace o vlastnostech a cílech nástroje Mono/WebAssembly MSBuild najdete v tématu WasmApp.Common.targets (dotnet/runtime úložiště GitHub).

Formát balení Webcil pro sestavení .NET

Webcil je webový formát balení pro sestavení .NET navržený tak, aby umožňoval použití Blazor WebAssembly v omezujících síťových prostředích. Soubory webcilu používají standardní obálku WebAssembly, kde jsou sestavení nasazena jako soubory WebAssembly, které používají standardní .wasm příponu souboru.

Webcil je výchozí formát balení při publikování Blazor WebAssembly aplikace. Chcete-li zakázat použití Webcil, nastavte v souboru projektu aplikace následující vlastnost MSBuild:

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

Přizpůsobte způsob načítání spouštěcích prostředků

Přizpůsobte, jak se načítají spouštěcí prostředky pomocí API loadBootResource. Další informace najdete v tématu ASP.NET Core Blazor startup.

Compression

Blazor WebAssembly Když je aplikace publikovaná, výstup se během publikování staticky komprimuje, aby se snížila velikost aplikace a odstranila režijní náklady na kompresi za běhu. Používají se následující algoritmy komprese:

• Brotli (nejvyšší úroveň)
• Gzip

Blazor spoléhá na hostitele, aby obsluhoval příslušné komprimované soubory. Při hostování Blazor WebAssembly samostatné aplikace může být potřeba další práce, aby se zajistilo, že se budou obsluhovat staticky komprimované soubory:

• Informace o konfiguraci komprese služby IIS web.config naleznete v části „IIS: Brotli a Gzip compression“.
• Při hostování na statických hostitelských řešeních, která nepodporují staticky komprimované vyjednávání obsahu souborů, zvažte konfiguraci aplikace pro načtení a dekódování komprimovaných souborů Brotli:

Získejte dekodér JavaScript Brotli z google/brotli úložiště GitHub. Minifikovaný soubor dekodéru se jmenuje decode.min.js a nachází se ve složcejs.

Note

Pokud minifikovaná verze decode.js skriptu (decode.min.js) selže, zkuste místo toho použít neminifikovanou verzi (decode.js).

Aktualizujte aplikaci tak, aby používala dekodér.

wwwroot/index.html Nastavte autostart na false ve značce Blazor souboru <script>:

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

Blazor Za značku <script> a před koncovou značku </body> přidejte následující blok kódu JavaScriptu <script>. Následující funkce volá fetch s cache: 'no-cache', aby se mezipaměť prohlížeče aktualizovala.

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>

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

Další informace o načítání spouštěcích prostředků najdete v tématu ASP.NET Core Blazor spuštění.

Pokud chcete zakázat kompresi, přidejte CompressionEnabled do souboru projektu aplikace vlastnost MSBuild a nastavte hodnotu na false:

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

CompressionEnabled Vlastnost můžete předat dotnet publish příkazu s následující syntaxí v příkazové řádce:

dotnet publish -p:CompressionEnabled=false

Přepsání adres URL pro správné směrování

Žádosti o směrování pro součásti stránek v Blazor WebAssembly aplikaci nejsou tak jednoduché jako žádosti o směrování v Blazor Server aplikaci. Blazor WebAssembly Zvažte aplikaci se dvěma komponentami:

• Main.razor: Načte se v kořenovém adresáři aplikace a obsahuje odkaz na komponentu About (href="About").
• About.razor: About komponenta.

Když se požaduje výchozí dokument aplikace pomocí adresního řádku prohlížeče (například https://www.contoso.com/):

1. Prohlížeč odešle žádost.
2. Vrátí se výchozí stránka, což je obvykle index.html.
3. index.html inicializuje aplikaci.
4. Router komponenta se načte a komponenta RazorMain se vykreslí.

Na hlavní stránce, vybráním odkazu na komponentu About funguje na klientovi, protože Blazor směrovač zastaví prohlížeč, aby neodeslal požadavek na Internet k www.contoso.com pro About a sám obsluhuje vykreslenou komponentu About. Všechny požadavky na interní endpointy v aplikaci Blazor WebAssembly fungují stejným způsobem: Požadavky nevyvolávají požadavky na základě prohlížeče na zdroje hostované na serveru na internetu. Směrovač zpracovává požadavky interně.

Pokud je žádost prováděna přes adresní řádek prohlížeče na www.contoso.com/About, požadavek selže. Na internetovém hostiteli aplikace neexistuje žádný takový prostředek, takže se vrátí odpověď 404 – Nenalezena .

Vzhledem k tomu, že prohlížeče pořadují požadavky na internetové hostitele pro klientské stránky, webové servery a hostitelské služby musí přepsat všechny požadavky na prostředky, které nejsou fyzicky na serveru, na stránku index.html. Jakmile se index.html vrátí, směrovač aplikace Blazor převezme řízení a odpoví správným prostředkem.

Při nasazování na server služby IIS můžete použít modul URL Rewrite s publikovaným souborem aplikace web.config. Další informace najdete v tématu Hostování a nasazení ASP.NET Core Blazor WebAssembly se službou IIS.

Samostatné nasazení

Samostatné nasazení slouží Blazor WebAssembly aplikaci jako sada statických souborů, které jsou přímo vyžadovány klienty. Kterýkoli statický souborový server je schopen poskytovat aplikaci Blazor.

Samostatné prostředky nasazení se publikují do složky /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot nebo bin/Release/{TARGET FRAMEWORK}/browser-wasm/publish, kde {TARGET FRAMEWORK} je zástupný symbol pro cílovou platformu.

Azure App Service

Blazor WebAssembly aplikace je možné nasadit do Azure App Services ve Windows, který je hostitelem aplikace ve službě IIS.

Nasazení samostatné Blazor WebAssembly aplikace do služby Aplikace Azure Service pro Linux se v současné době nepodporuje. Doporučujeme hostovat samostatnou Blazor WebAssembly aplikaci pomocí Azure Static Web Apps, která tento scénář podporuje.

Samostatný s Dockerem

Samostatná Blazor WebAssembly aplikace se publikuje jako sada statických souborů pro hostování statickým souborovým serverem.

Hostování aplikace v Dockeru:

• Zvolte kontejner Dockeru s podporou webového serveru, například Nginx nebo Apache.
• Zkopírujte soubory složky publish do určené složky na webovém serveru pro obsluhu statických souborů.
• Podle potřeby použijte další konfiguraci pro obsluhu Blazor WebAssembly aplikace.

Pokyny ke konfiguraci najdete v následujících zdrojích informací:

• Články o Nginx nebo Apache
• Dokumentace k Dockeru

Hodnoty konfigurace hostitele

Blazor WebAssembly aplikace mohou přijmout následující hodnoty konfigurace hostitele jako argumenty příkazového řádku za běhu ve vývojovém prostředí.

Kořenový adresář obsahu

Argument --contentroot nastaví absolutní cestu k adresáři, který obsahuje soubory obsahu aplikace (kořen obsahu). V následujících příkladech je /content-root-path kořenovou cestou obsahu aplikace.

• Předejte argument při místním spuštění aplikace na příkazovém řádku. V adresáři aplikace spusťte:

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

• Přidejte položku do souboru aplikace launchSettings.json v profilu IIS Express. Toto nastavení se používá při spuštění aplikace pomocí ladicího programu sady Visual Studio a z příkazového řádku s dotnet watch (nebo dotnet run).

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

• V sadě Visual Studio zadejte argument v části Vlastnosti>Ladění>Argumenty aplikace. Nastavení argumentu na stránce vlastností sady Visual Studio přidá argument do launchSettings.json souboru.

  --contentroot=/content-root-path
  

Základ cesty

Argument --pathbase nastaví základní cestu aplikace pro aplikaci spuštěnou místně s jinou než kořenovou relativní cestou URL ( <base> značka href je nastavená na jinou cestu než / pro přípravu a produkční prostředí). V následujících příkladech je /relative-URL-path základní cesta aplikace. Další informace najdete v ASP.NET Core Blazor základní cestě aplikace.

Important

Na rozdíl od cesty poskytnuté pro značky href<base>, nepřidávejte koncové lomítko (/) při předávání hodnoty argumentu --pathbase. Pokud je základní cesta aplikace ve <base> značce zadaná jako <base href="/CoolApp/"> (obsahuje koncové lomítko), předejte hodnotu argumentu příkazového řádku jako --pathbase=/CoolApp (bez koncového lomítka).

• Předejte argument při místním spuštění aplikace na příkazovém řádku. V adresáři aplikace spusťte:

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

• Přidejte položku do souboru aplikace launchSettings.json v profilu IIS Express. Toto nastavení se používá při spuštění aplikace pomocí ladicího programu sady Visual Studio a z příkazového řádku s dotnet watch (nebo dotnet run).

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

• V sadě Visual Studio zadejte argument v části Vlastnosti>Ladění>Argumenty aplikace. Nastavení argumentu na stránce vlastností sady Visual Studio přidá argument do launchSettings.json souboru.

  --pathbase=/relative-URL-path
  

Další informace najdete v ASP.NET Core Blazor základní cestě aplikace.

URLs

Argument --urls nastaví IP adresy nebo hostitelské adresy s porty a protokoly pro naslouchání požadavkům.

• Předejte argument při místním spuštění aplikace na příkazovém řádku. V adresáři aplikace spusťte:

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

• Přidejte položku do souboru aplikace launchSettings.json v profilu IIS Express. Toto nastavení se používá při spuštění aplikace pomocí ladicího programu sady Visual Studio a z příkazového řádku s dotnet watch (nebo dotnet run).

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

• V sadě Visual Studio zadejte argument v části Vlastnosti>Ladění>Argumenty aplikace. Nastavení argumentu na stránce vlastností sady Visual Studio přidá argument do launchSettings.json souboru.

  --urls=http://127.0.0.1:0
  

Nakonfigurujte ořezávač

Blazor provádí oříznutí zprostředkujícího jazyka (IL) na každém sestavení vydané verze, aby se z výstupních sestavení odebrala nepotřebná il. Další informace naleznete v tématu Konfigurace trimmeru pro ASP.NET Core Blazor.

Poškození předchozího nasazení

Obvykle při nasazení:

• Nahradí se jenom soubory, které se změnily, což obvykle vede k rychlejšímu nasazení.
• Existující soubory, které nejsou součástí nového nasazení, zůstanou na místě pro použití novým nasazením.

Ve výjimečných případech může přetrvání souborů z předchozího nasazení poškodit nové nasazení. Úplné odstranění existujícího nasazení (nebo místně publikované aplikace před nasazením) může vyřešit problém s poškozeným nasazením. K vyřešení problému často stačí jednou odstranit stávající nasazení, a to i v případě buildů a kanálů nasazení DevOps.

Pokud zjistíte, že vymazání předchozího nasazení se vždy vyžaduje, když se používá kanál buildu a nasazení DevOps, můžete dočasně přidat do kanálu buildu krok, který odstraní předchozí nasazení pro každé nové nasazení, dokud neodstraníte přesnou příčinu poškození.