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.

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í, která obsahuje informace o hostování Blazor WebAssembly aplikace jako podaplikace služby IIS.

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 <base> ve wwwroot/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í

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

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

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.

Poznámka:

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 <script> souboru Blazor:

<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 části 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é komponenty nasazení se publikují do složky /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot nebo bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish\ (v závislosti na verzi sady .NET SDK, kterou používáte), kde {TARGET FRAMEWORK} zástupný symbol představuje cílový rámec.

Azure App Service

Blazor WebAssemblyaplikace je možné nasadit do služby Azure App Services na Windows, který hostuje aplikaci na 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 (Statické webové aplikace)

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ílAzure, specifický cíl a Azure Static Web Apps, abyste vytvořili publikovací profil.

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ího programu 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 Podrobnosti nasazeníZdroj 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 Dokončit vytvořte publikovací profil. 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 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 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.

Vydání 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

IIS je schopný server pro statické soubory aplikací 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í ve složce /bin/Release/{TARGET FRAMEWORK}/publish nebo bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish, v závislosti na používané verzi sady SDK a umístění {TARGET FRAMEWORK} zástupného symbolu pro cílový framework. 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
• Jsou nastavena pravidla modulu přepsání adresy URL:
  • Obsluhujte podadresář, 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žijte vlastní web.config

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

1. Umístěte vlastní web.config soubor do kořenové složky projektu.
2. Publikujte projekt. Další informace najdete v tématu Hostitel a nasazení ASP.NET Core Blazor.

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 SDK soubor negeneruje, například v samostatné Blazor WebAssembly aplikaci na /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot nebo bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish, v závislosti na tom, kterou verzi SDK použijete a kde {TARGET FRAMEWORK} zástupný symbol je cílovým frameworkem, nastavte vlastnost <PublishIISAssets> na true v souboru projektu (.csproj). 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 soubor web.config nachází jinde, zadejte cestu k souboru v SourceFiles. Následující příklad určuje publish složku s $(PublishDir), a poskytuje cestu k DestinationFolder pro 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 je vyžadován modul URL Rewrite. 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ých aktiv aplikace.

Hostování jako podsložka 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 publikovaném souboru aplikace Blazor přidáním oddílu <handlers> do oddílu <system.webServer> souboru:

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

• Zakažte dědičnost sekce kořenové aplikace <system.webServer> pomocí prvku <location> s nastavením inheritInChildApplications na 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>
  

  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.

Odebrání obslužné rutiny nebo zakázání dědičnosti se provádí kromě konfigurace základní cesty aplikace. 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

Tato část se týká jenom samostatných Blazor WebAssembly aplikací.

Je možné nakonfigurovat službu IIS pomocí web.config tak, aby obsluhovala prostředky komprimované pomocí Brotli nebo Gzip pro samostatné Blazor WebAssembly aplikace. Příklad konfiguračního souboru naleznete v 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 požaduje 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 oddílu Použití vlastního web.config.

Ř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 se zabrání správci služby IIS načíst konfiguraci webu a webu ve poskytování statických souborů Blazor.

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.html.
• Nastavte cestu k dokumentu chyb na index.html. Razor komponenty a další koncové body, které nejsou soubory, nejsou umístěny na fyzických cestách ve statickém obsahu uloženém službou Blob. Když je přijat požadavek na jeden z těchto prostředků, který by měl Blazor směrovač zpracovat, chyba 404 – Nenalezeno, generovaná službou blobů, přesměruje požadavek na cestu k chybovému dokumentu. 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 Storage Exploreru (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 rychlosti pro NGINX aplikace mohou vyžadovat velkou hodnotu parametru pro zvládnutí relativně velkého 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. Vytvořte konfigurační soubor Apache. Následující příklad je zjednodušený konfigurační soubor (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. 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/wwwroot, kde zástupný symbol {TARGET FRAMEWORK} představuje cílový rámec) do adresáře /var/www/blazorapp (umístění, které bylo specifikováno pro DocumentRoot v konfiguračním souboru).

3. Restartujte službu Apache.

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

Stránky GitHubu

Následující pokyny pro nasazení aplikací Blazor WebAssembly na stránkách GitHub Pages demonstrují koncepty s interaktivním nástrojem nasazeným na GitHub Pages. Nástroj používá autoři dokumentace ASP.NET Core k vytvoření křížových odkazů (XREF) na dokumentaci k rozhraní API pro markdown článku:

• ukázková aplikace BlazorWebAssemblyXrefGenerator (blazor-samples/BlazorWebAssemblyXrefGenerator)
• webové stránky Live Xref Generator

Nastavení GitHub Pages

• akcí>obecné
  • oprávnění k akcím
    • Povolit podnikové akce a vybrat nepodnikové akce a opakovaně použitelné pracovní postupy> Povoleno (vybráno)
    • Povolit akce vytvořené GitHubem> Povoleno (vybráno)
    • Povolit akce a opakovaně použitelné pracovní postupy>stevesandersonms/ghaction-rewrite-base-href@v1,
  • oprávnění pracovního postupu>oprávnění ke čtení obsahu úložiště a balíčků
• Pages>Sestavení a nasazení
  • > GitHub Actions
  • Vybraný pracovní postup: Static HTML a založte skript akce pro statické nasazení na souboru Xref Generator static.yml nástroje Xref Generator. Konfigurace v souboru je popsaná v další části.
  • vlastní doména: Nastavte, jestli máte v úmyslu použít vlastní doménu, která není zahrnutá v těchto doprovodných materiálech. Další informace najdete v tématu Konfigurace vlastní domény pro web GitHub Pages.
  • Vynutit HTTPS> povoleno (vybraná možnost)

Konfigurace skriptu statického nasazení

Xref Generator static.yml soubor

Nakonfigurujte následující položky ve skriptu pro vaše nasazení:

• Publikovat adresář (PUBLISH_DIR): Použijte cestu ke složce úložiště, ve které je publikovaná aplikace Blazor WebAssembly. Aplikace je zkompilována pro konkrétní verzi .NET a část cesty odpovídající verzi se musí shodovat. Příklad: BlazorWebAssemblyXrefGenerator/bin/Release/net9.0/publish/wwwroot je cesta pro aplikaci, která používá net9.0TFM pro .NET SDK 9.0.
• Push path (on:push:paths): Nastavte cestu push tak, aby odpovídala složce úložiště aplikace se zástupným znakem **. Příklad: BlazorWebAssemblyXrefGenerator/**
• Verze sady .NET SDK (dotnet-version prostřednictvím actions/setup-dotnet akce): V současné době neexistuje způsob, jak nastavit verzi na 'nejnovější' (viz Povolení zadat 'nejnovější' jako dotnet-verze (actions/setup-dotnet #497) pro hlasování o žádosti o funkci). Nastavte verzi sady SDK alespoň tak vysokou jako verzi architektury aplikace.
• Cesta k publikování (dotnet publish příkaz): Nastavte cestu ke složce publikování na složku repozitáře aplikace. Příklad: dotnet publish BlazorWebAssemblyXrefGenerator -c Release
• Base HREF (base_href pro SteveSandersonMS/ghaction-rewrite-base-href Action): Nastavte základní href pro aplikaci na název úložiště. Příklad: Vlastník úložiště ukázky Blazor je dotnet. Název úložiště ukázky Blazor je blazor-samples. Když je nástroj Xref Generator nasazený na GitHub Pages, jeho webová adresa je založená na názvu úložiště (https://dotnet.github.io/blazor-samples/). Základní href aplikace je /blazor-samples/, která je nastavena na base_href pro Akci ghaction-rewrite-base-href, aby se při nasazení aplikace zapsala do značky aplikace wwwroot/index.html<base>. Další informace najdete v tématu Hostitel a nasazení ASP.NET Core Blazor.

Server Ubuntu hostovaný na GitHubu (nejnovější) má předinstalovanou verzi sady .NET SDK. Pokud předinstalovaná sada .NET SDK stačí ke kompilaci aplikace, můžete z actions/setup-dotnet skriptu odebrat krok . Pro určení nainstalované sady .NET SDK pro ubuntu-latest:

1. Přejděte do části Dostupné obrázky úložiště GitHub actions/runner-images.
2. Vyhledejte ubuntu-latest obrázek, což je první řádek tabulky.
3. Vyberte odkaz ve sloupci Included Software.
4. Posuňte se dolů k části .NET Tools, abyste viděli sadu nástrojů .NET Core SDK nainstalovanou s obrazem.

Poznámky k nasazení

Výchozí akce GitHubu, která nasazuje stránky, přeskočí nasazení složek počínaje podtržítkem, například _framework složku. Pokud chcete nasadit složky začínající podtržítkem, přidejte do kořenového adresáře úložiště aplikace prázdný soubor .nojekyll. Příklad: generátor Xref .nojekyll soubor

Tento krok proveďte před prvním nasazením aplikace: Git zachází se soubory JavaScriptu (JS), jako je blazor.webassembly.js, jako s textem a převádí konce řádků z CRLF (návrat vozíku a posun řádku) na LF (posun řádku) v nasazovacím kanálu. Tyto změny v JS souborech vytvářejí různé hashe souborů, které Blazor odesílají klientovi v blazor.boot.json souboru. Neshody vedou k selhání kontroly integrity na straně klienta. Jedním z přístupů k vyřešení tohoto problému je přidat .gitattributes soubor s řádkem *.js binary před tím, než se přidají prostředky aplikace do větve Git. Řádek *.js binary nakonfiguruje Git, aby nakládal se soubory JS jako s binárními soubory, což zamezuje jejich zpracování v kanálu nasazení. Hodnoty hash nezpracovaných souborů odpovídají položkám v souboru blazor.boot.json, a kontroly integrity na straně klienta byly úspěšné. Další informace najdete v tématu ASP.NET Core runtime .NET Blazor WebAssembly a ukládání do mezipaměti balíčků aplikací. Příklad: generátor Xref .gitattributes soubor

Zpracování přepisů adres URL na základě jednostrákových aplikací pro stránky GitHubu (rafrex/spa-github-pages úložiště GitHub):

• Přidejte soubor wwwroot/404.html se skriptem, který zpracovává přesměrování požadavku na stránku index.html. Příklad: generátor Xref 404.html soubor
• V wwwroot/index.htmlpřidejte skript do obsahu <head>. Příklad: generátor Xref index.html soubor

GitHub Pages nativně nepodporuje použití Brotli-komprimovaných prostředků. Použití Brotli:

• Přidejte skript wwwroot/decode.js do složky wwwroot aplikace. Příklad: generátor Xref decode.js soubor

• Přidejte značku <script> pro načtení skriptu decode.js do souboru wwwroot/index.html bezprostředně nad značku <script>, která načte Blazor skript. Příklad: generátor Xref index.html soubor

  • Nastavte autostart="false" pro skript Blazor WebAssembly.
  • Přidejte skript loadBootResource za značku <script>, která načte skript Blazor WebAssembly. Příklad: generátor Xref index.html soubor

• Přidání robots.txt a souborů sitemap.txt za účelem zlepšení SEO Příklady: Xref Generator robots.txt soubor, Xref Generator sitemap.txt soubor

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

• 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í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 tématu Základní cesta aplikace.

Důležité

Na rozdíl od cesty poskytnuté značky href<base> při předávání / hodnoty argumentu nezahrnujte koncové lomítko (--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 Vlastnostech>Ladění>Argumenty aplikace. 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 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>Debug>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.

Změna přípony názvu souboru DLL

Tato část platí pro ASP.NET Core 6.x a 7.x. V ASP.NET Core v .NET 8 nebo novějších se sestavení .NET nasazují jako soubory WebAssembly (.wasm) pomocí formátu souboru Webcil. V ASP.NET Core v .NET 8 nebo novějším platí tato část jenom v případě, že je v souboru projektu aplikace zakázaný formát souboru webcil.

Pokud brána firewall, antivirový program nebo zařízení pro zabezpečení sítě blokuje přenos souborů knihovny DLL aplikace (.dll), můžete podle pokynů v této části změnit přípony názvů souborů publikované knihovny DLL aplikace.

Poznámka:

Změna přípon názvů souborů DLL aplikace nemusí tento problém vyřešit, protože mnoho systémů zabezpečení kontroluje obsah souborů aplikace, nikoli pouze kontrolovat přípony souborů.

Pro robustnější přístup v prostředích, která blokují stahování a spouštění souborů DLL, použijte ASP.NET Core v .NET 8 nebo novějším, který zabalí sestavení .NET jako soubory WebAssembly (.wasm) pomocí formátu souboru Webcil . Další informace naleznete v části formát balení Webcil pro sestavení .NET v 8.0 nebo novější verzi tohoto článku.

Pro řešení tohoto problému existují přístupy třetích stran. Další informace naleznete na webu Awesome Blazor.

Po publikování aplikace pomocí skriptu prostředí nebo kanálu buildu DevOps přejmenujte .dll soubory tak, aby používaly jinou příponu souboru v adresáři publikovaného výstupu aplikace.

V následujících příkladech:

• K aktualizaci přípon souborů se používá PowerShell (PS).
• Soubory .dll jsou přejmenovány, aby používaly příponu souboru .bin z příkazového řádku.
• Soubory uvedené v publikovaném blazor.boot.json souboru s příponou .dll souboru se aktualizují na příponu .bin souboru.
• Pokud se také používají prostředky service worker, příkaz PowerShellu aktualizuje .dll soubory uvedené v service-worker-assets.js souboru na .bin příponu souboru.

Chcete-li použít jinou příponu souboru než .bin, nahraďte .bin v následujících příkazech požadovanou příponou souboru.

Ve 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

V předchozím příkazu {PATH} je zástupným symbolem cesta k publikované _framework složce (například .\bin\Release\net6.0\browser-wasm\publish\wwwroot\_framework z kořenové složky projektu).

Pokud se používají i prostředky pracovníka služby:

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

V předchozím příkazu {PATH} představuje zástupný symbol cestu k publikovanému service-worker-assets.js souboru.

V Linuxu nebo 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

V předchozím příkazu {PATH} je zástupným symbolem cesta k publikované _framework složce (například .\bin\Release\net6.0\browser-wasm\publish\wwwroot\_framework z kořenové složky projektu).

Pokud se používají i prostředky pracovního procesu služby:

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

V předchozím příkazu {PATH} představuje zástupný symbol cestu k publikovanému service-worker-assets.js souboru.

Pokud chcete řešit komprimované blazor.boot.json.gz soubory a blazor.boot.json.br soubory, použijte některý z následujících přístupů:

• Odeberte komprimované blazor.boot.json.gz soubory a blazor.boot.json.br soubory. Komprese je tímto přístupem zakázaná.
• Znovu zkomprimujte aktualizovaný blazor.boot.json soubor.

Předchozí pokyny pro komprimovaný blazor.boot.json soubor platí také v případě, že se používají soubory servisního pracovníka. Odstraňte nebo rekomprimujte service-worker-assets.js.br a service-worker-assets.js.gz. V opačném případě kontroly integrity souborů v prohlížeči selžou.

Následující příklad Windows pro .NET 6 používá skript PowerShellu umístěný v kořenovém adresáři projektu. Následující skript, který zakáže kompresi, je základem pro další úpravy, pokud chcete soubor znovu zkomprimovat blazor.boot.json .

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

Pokud jsou používána aktiva služebního pracovníka, přidejte následující příkazy.

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

V souboru projektu se skript spustí po publikování aplikace pro Release konfiguraci:

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

Poznámka:

Při přejmenování a opožděném načítání stejných sestavení najdete pokyny v opožděné načítání sestavení v ASP.NET Core Blazor WebAssembly.

Server aplikace obvykle vyžaduje konfiguraci statického obsahu pro obsluhu souborů s aktualizovanou příponou. Pro aplikaci hostované službou IIS přidejte položku mapy MIME (<mimeMap>) pro novou příponu souboru v oddílu statického obsahu (<staticContent>) ve vlastním web.config souboru. Následující příklad předpokládá, že přípona souboru je změněna z .dll :.bin

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

Pokud se komprese používá, uveďte aktualizaci komprimovaných souborů:

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

Odeberte položku pro příponu souboru .dll.

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

Odstraňte položky souborů, které byly komprimovány, pokud se používá komprese.

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

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

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

Ř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žívají tyto soubory. 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ádal nekonzistentní nebo neplatné odpovědi serveru, což může zabránit spuštění aplikace, přestože uživatel stránku zkusí aktualizovat 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 platný digest v atributu 'integrity' pro prostředek 'https://myapp.example.com/_framework/MyBlazorApp.dll' s 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.

Poznámka:

Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro konkrétní verzi, použijte rozevírací seznam pro přepnutí větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

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, který je třeba diagnostikovat.
5. Pomocí skriptu PowerShell pro ověření integrity ověřte 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. K prošetření tohoto:

• 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). Je v pořádku, když webový server implementuje kompresi HTTP (například vrací content-encoding: br nebo content-encoding: gzip), protože to nemá vliv na výsledek po dekompresi. Není 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 složce publish stažené z nasazené aplikace, aby zjistil problémy v různých manifestech, které obsahují 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áno koncové lomítko (/).
• {PUBLISH OUTPUT FOLDER}: Cesta ke složce nebo umístění aplikace publish , kde je aplikace publikovaná pro nasazení.

Poznámka:

Při klonování dotnet/AspNetCore.Docs úložiště integrity.ps1 GitHub může skript umístit do karantény Bitdefender nebo jiný virový skener, který je v systému. Soubor je obvykle zachycen heuristickým skenovací technologií antivirového skeneru, který pouze hledá vzory v souborech, které by mohly znamenat přítomnost malwaru. Před klonováním úložiště přidejte do virového skeneru výjimku, abyste zabránili, aby virový skener umístil soubor do karantény. Následující příklad představuje typickou cestu ke skriptu v systému Windows. Upravte cestu podle potřeby pro jiné systémy. Zástupný symbol {USER} je segment cesty uživatele.

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

Upozornění: Vytváření výjimek antivirového skeneru je nebezpečné a mělo by se provést pouze v případě, že jste si jisti, že je soubor bezpečný.

Porovnání kontrolního součtu souboru s platnou hodnotou kontrolního součtu nezaručuje bezpečnost souborů, ale úprava souboru způsobem, který udržuje hodnotu kontrolního součtu, není pro uživatele se zlými úmysly triviální. Kontrolní součty jsou proto užitečné jako obecný přístup k zabezpečení. Porovnejte kontrolní součet místního integrity.ps1 souboru s jednou z následujících hodnot:

• SHA256: 32c24cb667d79a701135cb72f6bae490d81703323f61b8af2c7e5e5dc0f0c2bb
• MD5: 9cee7d7ec86ee809a329b5406fbf21a8

Pomocí následujícího příkazu získejte kontrolní součet souboru v operačním systému Windows. Zadejte cestu a název souboru pro zástupný symbol {PATH AND FILE NAME} a uveďte typ kontrolního součtu, který se má vytvořit pro zástupný symbol {SHA512|MD5}, buď SHA256 nebo MD5:

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

Pokud máte nějaké obavy, že ověření kontrolního součtu není ve vašem prostředí dostatečně zabezpečené, projděte si pokyny ve vedení vaší organizace v oblasti zabezpečení.

Další informace najdete v tématu Přehled ochrany před hrozbami Microsoft Defender Antivirus.

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é deaktivuje výchozí chování Blazor ukládání do mezipaměti .dll, .wasm a dalších souborů na základě jejich hash SHA-256, protože vlastnost oznamuje, že hodnoty hash SHA-256 nejsou spolehlivé z hlediska správnosti. 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ží.

Poznámka:

Tato BlazorCacheBootResources vlastnost nezakazuje kontroly integrity progresivních webových aplikací (PWA). Pokyny týkající se PWA najdete v části Zakázání kontroly integrity PWA.

Nemůžeme poskytnout úplný seznam scénářů, ve kterých je vyžadováno deaktivování kontroly 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 nelze 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.