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

Tento článek vysvětluje, jak hostovat a nasazovat Blazor WebAssembly pomocí služby ASP.NET Core, Content Delivery Networks (CDN), souborových serverů a stránek GitHubu.

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.

Subdoména a hostitel 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 (<base>značku vwwwroot/index.html).

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í

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

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

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

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

Komprese

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

• Informace o konfiguraci komprese služby IIS web.config naleznete v části Iis: Brotli a Gzip compression section.
• 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žce úložištějs.

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

wwwroot/index.html V souboru nastavte autostart na false Blazorznačku ' s<script>:

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

<script> Za Blazorznačku a před koncovou </body> značku přidejte následující blok kódu <script> JavaScriptu.

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

<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 Spuštění CoreBlazor.

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

dotnet publish -p:CompressionEnabled=false

<PropertyGroup>
  <BlazorEnableCompression>false</BlazorEnableCompression>
</PropertyGroup>

dotnet publish -p:BlazorEnableCompression=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 součást.

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 bootstraps the app.
4. Router komponenta se načte a komponenta RazorMain se vykreslí.

Na hlavní stránce vyberete odkaz na komponentu About , která funguje na klientovi, protože Blazor směrovač zastaví prohlížeč v tom, aby www.contoso.com About na internetu udělal požadavek a obsluhuje samotnou vykreslovanou About komponentu. Všechny požadavky na interní koncové body v aplikaci Blazor WebAssembly fungují stejným způsobem: Požadavky neaktivují žádosti na základě prohlížeče na prostředky hostované serverem na internetu. Směrovač zpracovává požadavky interně.

Pokud se žádost provede pomocí adresního řádku prohlížeče, www.contoso.com/Aboutpož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řují požadavky na internetové hostitele na stránky na straně klienta, webové servery a hostitelské služby musí přepsat všechny požadavky na prostředky, které nejsou fyzicky na serveru na index.html stránce. Jakmile index.html se vrátí, směrovač aplikace Blazor převezme a odpoví správným prostředkem.

Při nasazování na server SLUŽBY IIS můžete použít modul pro přepsání adresy URL s publikovaným web.config souborem aplikace. Další informace najdete v části IIS .

<SelfContained>false</SelfContained>

<RuntimeIdentifier>{RID}</RuntimeIdentifier>

<SelfContained>false</SelfContained>

Samostatné nasazení

Samostatné nasazení slouží Blazor WebAssembly aplikaci jako sada statických souborů, které jsou požadovány přímo klienty. Aplikace může obsluhovat Blazor jakýkoli statický souborový server.

Samostatné prostředky nasazení se publikují do složky /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot nebo bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish\ do složky (v závislosti na používané verzi sady .NET SDK), kde {TARGET FRAMEWORK} zástupný symbol představuje cílovou architekturu.

Azure App Service

Blazor WebAssemblyaplikace je možné nasadit do služby Aplikace Azure Services ve Windows, které hostuje aplikaci 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.

Azure Static Web Apps

K nasazení Blazor WebAssembly aplikace do Azure Static Web Apps použijte jeden z následujících přístupů:

• Nasazení ze sady Visual Studio
• Nasazení z editoru Visual Studio Code
• Nasazení z GitHubu

Nasazení ze sady Visual Studio

Pokud chcete nasadit ze sady Visual Studio, vytvořte profil publikování pro Azure Static Web Apps:

1. Uložte všechny neuložené práce v projektu, protože během procesu může být vyžadováno restartování sady Visual Studio.

2. V uživatelském rozhraní pro publikování sady Visual Studio vyberte Cílové>cílové azure>>Static Web Apps a vytvořte profil publikování.

3. Pokud není nainstalovaná komponenta Azure WebJobs Tools pro Visual Studio, zobrazí se výzva k instalaci komponenty pro ASP.NET a vývoj webu. Podle pokynů nainstalujte nástroje pomocí Instalační program pro Visual Studio. Visual Studio se při instalaci nástrojů automaticky zavře a znovu otevře. Po instalaci nástrojů začněte od prvního kroku a vytvořte profil publikování.

4. V konfiguraci profilu publikování zadejte název předplatného. Vyberte existující instanci nebo vyberte Vytvořit novou instanci. Při vytváření nové instance v uživatelském rozhraní vytvořit statickou webovou aplikaci na webu Azure Portal nastavte zdroj podrobností>nasazení na jiný. Než budete pokračovat, počkejte na dokončení nasazení na webu Azure Portal.

5. V konfiguraci profilu publikování vyberte instanci Azure Static Web Apps ze skupiny prostředků instance. Výběrem možnosti Dokončit vytvořte profil publikování. Pokud visual Studio vyzve k instalaci rozhraní příkazového řádku Static Web Apps (SWA), nainstalujte rozhraní příkazového řádku podle pokynů. Rozhraní příkazového řádku SWA vyžaduje NPM/Node.js (Dokumentace k sadě Visual Studio).

Po vytvoření profilu publikování nasaďte aplikaci do instance Azure Static Web Apps pomocí profilu publikování výběrem tlačítka Publikovat .

Nasazení z editoru Visual Studio Code

Pokud chcete nasadit z editoru Visual Studio Code, přečtěte si článek Rychlý start: Vytvoření prvního statického webu pomocí Azure Static Web Apps.

Nasazení z GitHubu

Pokud chcete nasadit z úložiště GitHub, přečtěte si kurz : Vytvoření statické webové aplikace v Blazor Azure Static Web Apps.

IIS

Služba IIS je pro aplikace schopný statický souborový server Blazor . Informace o konfiguraci služby IIS pro hostování Blazornajdete v tématu Vytvoření statického webu ve službě IIS.

Publikované prostředky se vytvářejí v /bin/Release/{TARGET FRAMEWORK}/publish bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish závislosti na používané verzi sady SDK a umístění {TARGET FRAMEWORK} zástupného symbolu cílové architektury. Hostujte obsah publish složky na webovém serveru nebo hostitelské službě.

web.config

Blazor Při publikování web.config projektu se vytvoří soubor s následující konfigurací služby IIS:

• typy MIME
• Komprese HTTP je povolená pro následující typy MIME:
  • application/octet-stream
  • application/wasm
• Navazují se pravidla modulu přepsání adresy URL:
  • Obsluha podadresáři, ve kterém se nacházejí statické prostředky aplikace (wwwroot/{PATH REQUESTED}).
  • Vytvořte náhradní směrování SPA tak, aby se požadavky na jiné prostředky než soubor přesměrovaly do výchozího dokumentu aplikace ve složce statických prostředků (wwwroot/index.html).

Použití vlastního web.config

Použití vlastního web.config souboru:

Pokud generování nebo transformace sady SDK web.config během publikování buď nepřesune soubor do publikovaných prostředků ve publish složce nebo upraví vlastní konfiguraci ve vašem vlastním web.config souboru, použijte k úplnému řízení procesu některý z následujících přístupů:

• Pokud sada SDK soubor negeneruje, například v samostatné aplikaci v závislosti na tom, ve které verzi sady SDK se používá a kde {TARGET FRAMEWORK} je zástupný symbol cílovou architekturou, nastavte <PublishIISAssets> vlastnost v true souboru projektu (.csproj).bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish/bin/Release/{TARGET FRAMEWORK}/publish/wwwroot Blazor WebAssembly U samostatných aplikací WebAssembly se obvykle jedná o jediné požadované nastavení pro přesunutí vlastního web.config souboru a zabránění transformaci souboru sadou SDK.

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

• Zakažte transformaci sady SDK web.config v souboru projektu (.csproj):

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

• Přidejte vlastní cíl do souboru projektu (.csproj) pro přesunutí vlastního web.config souboru. V následujícím příkladu je vlastní web.config soubor umístěn vývojářem v kořenovém adresáři projektu. Pokud se web.config soubor nachází jinde, zadejte cestu k souboru v souboru .SourceFiles Následující příklad určuje publish složku s $(PublishDir), ale zadejte cestu k DestinationFolder vlastní výstupní umístění.

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

Instalace modulu pro přepsání adresy URL

K přepsání adres URL se vyžaduje modul pro přepsání adres URL. Modul není ve výchozím nastavení nainstalovaný a není k dispozici pro instalaci jako funkce služby role Webový server (IIS). Modul se musí stáhnout z webu služby IIS. Pomocí instalačního programu webové platformy nainstalujte modul:

1. Místně přejděte na stránku pro stažení modulu pro přepsání adresy URL. Pro anglickou verzi vyberte WebPI a stáhněte instalační program WebPI. V případě jiných jazyků vyberte příslušnou architekturu pro server (x86/x64) a stáhněte instalační program.
2. Zkopírujte instalační program na server. Spusťte instalační program. Vyberte tlačítko Instalovat a přijměte licenční podmínky. Po dokončení instalace se nevyžaduje restartování serveru.

Konfigurace webu

Nastavte fyzickou cestu webu ke složce aplikace. Složka obsahuje:

• Soubor web.config , který služba IIS používá ke konfiguraci webu, včetně požadovaných pravidel přesměrování a typů obsahu souborů.
• Složka statického prostředku aplikace.

Hostování jako dílčí aplikace SLUŽBY IIS

Pokud je samostatná aplikace hostovaná jako dílčí aplikace služby IIS, proveďte jednu z následujících akcí:

• Zakažte zděděnou obslužnou rutinu modulu ASP.NET Core.

  Odeberte obslužnou rutinu v Blazor publikovaném web.config souboru aplikace přidáním <handlers> oddílu <system.webServer> do oddílu souboru:

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

• Zakažte dědičnost oddílu kořenové (nadřazené) aplikace <system.webServer> pomocí elementu se inheritInChildApplications nastavenou <location> nafalse:

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

  Poznámka:

  Zakázání dědičnosti kořenové (nadřazené) části aplikace <system.webServer> je výchozí konfigurace publikovaných aplikací pomocí sady .NET SDK.

Kromě konfigurace základní cesty aplikace se provádí odebrání obslužné rutiny nebo zakázání dědičnosti. Nastavte základní cestu aplikace v souboru aplikace index.html na alias IIS použitý při konfiguraci dílčí aplikace ve službě IIS.

Základní cestu aplikace nakonfigurujte podle pokynů v článku Hostitel a nasaďte ASP.NET Core Blazor .

Komprese Brotli a Gzip

Službu IIS je možné nakonfigurovat tak web.config , aby obsluhovala komprimované Blazor prostředky Brotli nebo Gzip pro samostatné Blazor WebAssembly aplikace. Příklad konfiguračního souboru naleznete v tématu web.config.

V následujících scénářích může být vyžadována další konfigurace ukázkového web.config souboru:

• Specifikace aplikace volá jednu z následujících možností:
  • Obsluha komprimovaných souborů, které nejsou nakonfigurované ukázkovým web.config souborem.
  • Obsluha komprimovaných souborů nakonfigurovaných ukázkovým web.config souborem v nekomprimovaném formátu
• Konfigurace služby IIS serveru (například applicationHost.config) poskytuje výchozí hodnoty služby IIS na úrovni serveru. V závislosti na konfiguraci na úrovni serveru může aplikace vyžadovat jinou konfiguraci služby IIS, než jaký ukázkový web.config soubor obsahuje.

Další informace o vlastních web.config souborech najdete v části Použití vlastního web.config oddílu.

Řešení problému

Pokud se zobrazí chyba 500 – Vnitřní chyba serveru a Správce služby IIS při pokusu o přístup ke konfiguraci webu vyvolá chyby, ověřte, že je nainstalovaný modul pro přepsání adresy URL. Pokud modul není nainstalovaný, web.config nejde soubor analyzovat službou IIS. Tím zabráníte správci služby IIS načíst konfiguraci webu a web v poskytování Blazorstatických souborů.

Další informace o řešení potíží s nasazeními do služby IIS najdete v tématu Řešení potíží ASP.NET Core ve službě Aplikace Azure a službě IIS.

Azure Storage

Hostování statických souborů Azure Storage umožňuje hostování bezserverových Blazor aplikací. Podporují se vlastní názvy domén, Azure Content Delivery Network (CDN) a HTTPS.

Pokud je pro hostování statického webu v účtu úložiště povolená služba Blob Service:

• Nastavte název dokumentu rejstříku na index.htmlhodnotu .
• Nastavte cestu k dokumentu Chyba na index.htmlhodnotu . Razor komponenty a další koncové body, které nejsou soubory, se nenakládají na fyzických cestách ve statickém obsahu uloženém službou Blob Service. Když se zobrazí požadavek na jeden z těchto prostředků, který Blazor by měl směrovač zpracovat, chyba 404 – Nenalezena generovaná službou blob service směruje požadavek na cestu k dokumentu Chyba. Vrátí se index.html objekt blob a Blazor směrovač načte a zpracuje cestu.

Pokud se soubory nenačtou za běhu kvůli nevhodným typům MIME v hlavičce souborů Content-Type , proveďte jednu z následujících akcí:

• Nakonfigurujte nástroje tak, aby při nasazení souborů nastavily správné typy MIME (Content-Type hlavičky).

• Po nasazení aplikace změňte typy MIME (Content-Type hlavičky) pro soubory.

  V Průzkumník služby Storage (Azure Portal) pro každý soubor:

  1. Klikněte na soubor pravým tlačítkem a vyberte Vlastnosti.
  2. Nastavte contentType a vyberte tlačítko Uložit.

Další informace najdete v tématu Hostování statického webu ve službě Azure Storage.

Nginx

Následující nginx.conf soubor je zjednodušený a ukazuje, jak nakonfigurovat Nginx tak, aby soubor odesílal index.html , kdykoli nemůže najít odpovídající soubor na disku.

events { }
http {
    server {
        listen 80;

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

Při nastavování limitu Blazor WebAssembly limit_reqrychlosti nárazové rychlosti NGINX u aplikací můžou aplikace vyžadovat velkou burst hodnotu parametru, aby vyhovovala relativně velkému počtu požadavků provedených aplikací. Zpočátku nastavte hodnotu alespoň na 60:

http {
    server {
        ...

        location / {
            ...

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

Zvyšte hodnotu, pokud vývojářské nástroje prohlížeče nebo nástroj síťového provozu indikují, že požadavky dostávají stavový kód 503 – Služba není k dispozici .

Další informace o konfiguraci webového serveru Nginx v produkčním prostředí naleznete v tématu Vytváření konfiguračních souborů NGINX Plus a NGINX.

Apache

Blazor WebAssembly Nasazení aplikace do Apache:

1. Umístěte konfigurační soubor Apache do /etc/httpd/conf.d/ adresáře.

2. Umístěte publikované prostředky aplikace (/bin/Release/{TARGET FRAMEWORK}/publish/wwwrootkde {TARGET FRAMEWORK} zástupný symbol představuje cílovou architekturu) do /var/www/blazorapp adresáře (umístění určené v DocumentRoot konfiguračním souboru).

3. Restartujte službu Apache.

Další informace najdete v tématech mod_mime a mod_deflate.

Stránky GitHubu

Výchozí akce GitHubu, která nasazuje stránky, přeskočí nasazení složek začínajících podtržítkem, _framework například složky. Pokud chcete nasadit složky začínající podtržítkem, přidejte do větve Git prázdný .nojekyll soubor.

Git zpracovává soubory JavaScriptu (JS), jako blazor.webassembly.jsje text a převádí konce řádků z CRLF (kanál návratového řádku řádku) na LF (kanál řádku) v kanálu nasazení. Tyto změny v JS souborech vytvářejí různé hodnoty hash souborů, než Blazor se odesílají klientovi v blazor.boot.json souboru. Neshoda vede k selhání kontroly integrity v klientovi. Jedním z přístupů k vyřešení tohoto problému je přidání .gitattributes souboru s řádkem *.js binary před přidáním prostředků aplikace do větve Git. Řádek *.js binary nakonfiguruje Git tak, aby se soubory zpracovávaly JS jako binární soubory, což zabraňuje zpracování souborů v kanálu nasazení. Hodnoty hash souboru nezpracovaných souborů odpovídají položkám v blazor.boot.json souboru a úspěšné kontroly integrity na straně klienta. Další informace najdete v tématu ASP.NET Modulu runtime .NET Core Blazor WebAssembly a ukládání do mezipaměti sady aplikací.

Pokud chcete zpracovat přepsání adresy URL, přidejte wwwroot/404.html soubor se skriptem, který zpracovává přesměrování požadavku na index.html stránku. Příklad najdete v úložišti SteveSandersonMS/BlazorOnGitHubPagesGitHub:

• wwwroot/404.html
• Živý web

Při použití webu projektu místo webu organizace aktualizujte <base> značku v wwwroot/index.htmlsouboru . Nastavte hodnotu atributu href na název úložiště GitHubu pomocí koncového lomítka (například /my-repository/). V úložišti SteveSandersonMS/BlazorOnGitHubPagesGitHub se základ href aktualizuje při publikování konfiguračním .github/workflows/main.yml souborem.

Samostatná služba 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:

• Vyberte kontejner Dockeru s podporou webového serveru, například Ngnix nebo Apache.
• publish Zkopírujte prostředky složky do složky umístění definované 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í:

• Oddíl Nginx nebo oddíl Apache tohoto článku
• 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řen obsahu

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

• 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 SLUŽBY 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 argumentech Aplikace ladění>vlastností>. 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íchpříkladch /relative-URL-path Další informace najdete v tématu Základní cesta 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 --pathbase=/relative-URL-path
  

• Přidejte položku do souboru aplikace launchSettings.json v profilu SLUŽBY 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 argumentech Aplikace ladění>vlastností>. Nastavení argumentu na stránce vlastností sady Visual Studio přidá argument do launchSettings.json souboru.

  --pathbase=/relative-URL-path
  

Adresy URL

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 SLUŽBY 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 argumentech Aplikace ladění>vlastností>. Nastavení argumentu na stránce vlastností sady Visual Studio přidá argument do launchSettings.json souboru.

  --urls=http://127.0.0.1:0
  

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

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

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

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

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

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

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

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

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

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

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

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, včetně buildu DevOps a kanálu nasazení, často stačí odstranit stávající nasazení.

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

Řešení chyb kontroly integrity

Když Blazor WebAssembly stáhne spouštěcí soubory aplikace, dá prohlížeči pokyn, aby u odpovědí provedl kontroly integrity. Blazor odesílá hodnoty hash SHA-256 pro knihovnu DLL (.dll), WebAssembly (.wasm) a další soubory v blazor.boot.json souboru, které nejsou uloženy v mezipaměti klientů. Hodnoty hash souborů uložených v mezipaměti se porovnávají s hodnotami hash v blazor.boot.json souboru. U souborů uložených v mezipaměti s odpovídající hodnotou hash Blazor se používá soubory uložené v mezipaměti. V opačném případě se ze serveru požadují soubory. Po stažení souboru se znovu zkontroluje jeho hodnota hash pro ověření integrity. Prohlížeč vygeneruje chybu, pokud se nezdaří kontrola integrity staženého souboru.

Blazoralgoritmus pro správu integrity souborů:

• Zajišťuje, že aplikace neriskuje načtení nekonzistentní sady souborů, například pokud se na webový server použije nové nasazení, zatímco uživatel právě stahuje soubory aplikace. Nekonzistentní soubory můžou vést k nesprávné aplikaci.
• Zajišťuje, aby prohlížeč uživatele nikdy neukládaly nekonzistentní nebo neplatné odpovědi, což může zabránit spuštění aplikace, i když uživatel stránku aktualizuje ručně.
• Zajistí bezpečnost ukládání odpovědí do mezipaměti a nezkontroluje změny na straně serveru, dokud se očekávané hodnoty hash SHA-256 nezmění, takže následné načtení stránky zahrnuje méně požadavků a dokončí se rychleji.

Pokud webový server vrátí odpovědi, které neodpovídají očekávaným hodnotám hash SHA-256, zobrazí se v konzole pro vývojáře prohlížeče chyba podobná následujícímu příkladu:

Nepodařilo se najít platnou hodnotu hash v atributu integrity prostředku shttps://myapp.example.com/_framework/MyBlazorApp.dll vypočítanou integritou SHA-256 IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY=. Prostředek je zablokovaný.

Ve většině případů upozornění neoznačuje problém s kontrolou integrity. Místo toho upozornění obvykle znamená, že existuje nějaký jiný problém.

Blazor WebAssemblyReferenční zdroj spouštění najdete Boot.WebAssembly.ts v souboru v dotnet/aspnetcore úložišti GitHub.

Diagnostika problémů integrity

Když je aplikace sestavená, vygenerovaný blazor.boot.json manifest popisuje hodnoty hash SHA-256 spouštěcích prostředků v době, kdy se vytvoří výstup sestavení. Kontrola integrity projde tak dlouho, dokud hodnoty hash SHA-256 odpovídají blazor.boot.json souborům doručeným do prohlížeče.

Mezi běžné důvody selhání patří:

• Odpověď webového serveru je chyba (například 404 – Nenalezena nebo 500 – Vnitřní chyba serveru) místo požadovaného souboru v prohlížeči. Prohlížeč ho hlásí jako selhání kontroly integrity, a ne jako selhání odpovědi.
• Něco změnilo obsah souborů mezi sestavením a doručením souborů do prohlížeče. Může k tomu dojít:
  • Pokud vy nebo nástroje sestavení ručně upravíte výstup sestavení.
  • Pokud některé aspekty procesu nasazení změnily soubory. Pokud například používáte mechanismus nasazení založený na Gitu, mějte na paměti, že Git transparentně převádí konce čar ve stylu Windows na konce čar ve stylu Unix, pokud potvrdíte soubory ve Windows a zkontrolujete je v Linuxu. Změna konce řádku souboru změní hodnoty hash SHA-256. Pokud se chcete tomuto problému vyhnout, zvažte použití .gitattributes ke zpracování artefaktů sestavení jako binary souborů.
  • Webový server upraví obsah souboru jako součást jejich poskytování. Například některé distribuční sítě obsahu (CDN) se automaticky pokusí minifikovat KÓD HTML, čímž ho upraví. Tyto funkce možná budete muset zakázat.
• Soubor blazor.boot.json se nenačte správně nebo je nesprávně uložen v mezipaměti klienta. Mezi běžné příčiny patří:
  • Chybná konfigurace nebo selhání vlastního vývojářského kódu
  • Jedna nebo více chybně nakonfigurovaných mezilehlých vrstev ukládání do mezipaměti

Pokud chcete diagnostikovat, které z těchto možností platí ve vašem případě:

1. Všimněte si, který soubor chybu aktivuje, čtením chybové zprávy.
2. Otevřete vývojářské nástroje prohlížeče a podívejte se na kartu Síť . V případě potřeby stránku znovu načtěte, aby se zobrazil seznam požadavků a odpovědí. Najděte soubor, který v seznamu aktivuje chybu.
3. Zkontrolujte stavový kód HTTP v odpovědi. Pokud server vrátí cokoli jiného než 200 – OK (nebo jiný stavový kód 2xx), máte k diagnostice problém na straně serveru. Stavový kód 403 například znamená problém s autorizací, zatímco stavový kód 500 znamená, že server selhává způsobem, který není zadaný. Pokud chcete diagnostikovat a opravit aplikaci, projděte si protokoly na straně serveru.
4. Pokud je stavový kód 200 – OK prostředku, podívejte se na obsah odpovědi v vývojářských nástrojích prohlížeče a zkontrolujte, jestli obsah odpovídá očekávaným datům. Běžným problémem je například chybné konfigurace směrování tak, aby žádosti vracely vaše index.html data i pro jiné soubory. Ujistěte se, že odpovědi na .wasm požadavky jsou binární soubory WebAssembly a že odpovědi na .dll požadavky jsou binární soubory sestavení .NET. Pokud ne, máte problém se směrováním na straně serveru k diagnostice.
5. Pomocí skriptu PowerShellu pro řešení potíží s integritou vyhledejte publikovaný a nasazený výstup aplikace.

Pokud potvrdíte, že server vrací důvěryhodně správná data, mezi sestavením a doručením souboru musí být něco jiného, co upravuje obsah. Prošetření:

• Prozkoumejte sadu nástrojů sestavení a mechanismus nasazení v případě, že po sestavení souborů upravují soubory. Příkladem je, když Git transformuje konce řádků souboru, jak je popsáno výše.
• Zkontrolujte konfiguraci webového serveru nebo CDN v případě, že jsou nastavené tak, aby dynamicky upravovali odpovědi (například při pokusu o minifikaci KÓDU HTML). Webový server je v pořádku implementovat kompresi HTTP (například vrácení content-encoding: br nebo content-encoding: gzip), protože to nemá vliv na výsledek po dekompresi. Není ale v pořádku, aby webový server upravil nekomprimovaná data.

Řešení potíží se skriptem PowerShellu pro integritu

Pomocí skriptu PowerShellu integrity.ps1 ověřte publikovanou a nasazenou Blazor aplikaci. Skript se poskytuje pro PowerShell Core 7 nebo novější jako výchozí bod, když má aplikace problémy s integritou, které Blazor architektura nedokáže identifikovat. Přizpůsobení skriptu může být vyžadováno pro vaše aplikace, včetně toho, jestli běží ve verzi PowerShellu novější než verze 7.2.0.

Skript zkontroluje soubory ve publish složce a stáhne z nasazené aplikace, aby zjistil problémy v různých manifestech obsahujících hodnoty hash integrity. Tyto kontroly by měly detekovat nejběžnější problémy:

• Upravili jste soubor v publikovaném výstupu, aniž byste si ho uvědomili.
• Aplikace nebyla správně nasazená do cíle nasazení nebo se v prostředí cíle nasazení změnila.
• Mezi nasazenou aplikací a výstupem publikování aplikace existují rozdíly.

V příkazovém prostředí PowerShellu spusťte skript pomocí následujícího příkazu:

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

V následujícím příkladu se skript spustí v místně spuštěné aplikaci na https://localhost:5001/adrese:

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

Zástupné symboly:

• {BASE URL}: Adresa URL nasazené aplikace. Je vyžadován koncové lomítko (/).
• {PUBLISH OUTPUT FOLDER}: Cesta ke složce nebo umístění aplikace publish , kde je aplikace publikovaná pro nasazení.

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

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

Zakázání kontroly integrity pro aplikace bez PWA

Ve většině případů nezakazujte kontrolu integrity. Zakázání kontroly integrity nevyřeší základní problém, který způsobil neočekávané odpovědi a výsledkem je ztráta dříve uvedených výhod.

V případech, kdy se webový server nedá spoléhat na vrácení konzistentních odpovědí a nemáte na výběr, ale dočasně zakázat kontroly integrity, dokud se nevyřeší základní problém.

Pokud chcete zakázat kontroly integrity, přidejte následující položky do skupiny vlastností v Blazor WebAssembly souboru projektu aplikace (.csproj):

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResources také zakáže Blazorvýchozí chování ukládání do mezipaměti .dll, .wasma další soubory na základě jejich hash SHA-256, protože vlastnost označuje, že hodnoty hash SHA-256 nelze spoléhat na správnost. I při tomto nastavení může normální mezipaměť HTTP prohlížeče tyto soubory ukládat do mezipaměti, ale to, jestli k tomu dojde, závisí na konfiguraci webového serveru a cache-control hlavičkách, které slouží.

Nemůžeme poskytnout úplný seznam scénářů, ve kterých je vyžadována kontrola integrity. Servery můžou odpovědět na požadavek libovolným způsobem mimo rozsah Blazor architektury. Architektura poskytuje BlazorCacheBootResources nastavení, které aplikaci umožní spustit za cenu ztráty záruky integrity, kterou může aplikace poskytnout. Opět nedoporučujeme zakázat kontrolu integrity, zejména pro produkční nasazení. Vývojáři by se měli snažit vyřešit základní problém integrity, který způsobuje selhání kontroly integrity.

Mezi obecné případy, které můžou způsobit problémy s integritou, patří:

• Běží na http, kde nejde zkontrolovat integritu.
• Pokud proces nasazení změní soubory po publikování jakýmkoli způsobem.
• Pokud váš hostitel soubory nějakým způsobem upraví.

Zakázání kontroly integrity pro PWA

BlazorŠablona progresivní webové aplikace (PWA) obsahuje navrhovaný service-worker.published.js soubor, který je zodpovědný za načítání a ukládání souborů aplikací pro offline použití. Jedná se o samostatný proces od normálního spouštěcího mechanismu aplikace a má vlastní samostatnou logiku kontroly integrity.

service-worker.published.js Uvnitř souboru je k dispozici následující řádek:

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

Chcete-li zakázat kontrolu integrity, odeberte integrity parametr změnou řádku na následující:

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

Zákaz kontroly integrity opět znamená, že ztratíte bezpečnostní záruky nabízené kontrolou integrity. Existuje například riziko, že pokud prohlížeč uživatele ukládá aplikaci do mezipaměti v přesně okamžiku, kdy nasadíte novou verzi, může ukládat některé soubory ze starého nasazení do mezipaměti a některé z nových nasazení. Pokud k tomu dojde, aplikace se zasekne v nefunkčním stavu, dokud nenasadíte další aktualizaci.