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

S Blazor WebAssembly modelem hostování:

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

Podporují se následující strategie nasazení:

• Aplikaci Blazor obsluhou používá ASP.NET Core aplikace. Tato strategie je ována v části Hostované nasazení s ASP.NET Core.
• Aplikace je umístěná na statický hostující webový server nebo službu, kde se .NET k obsluhu aplikace Blazor Blazor nepouží. Tato strategie je probádá v části Samostatné nasazení, která obsahuje informace o hostování aplikace jako Blazor WebAssembly dílčí aplikace služby IIS.

Kompilace předem (AOT)

Blazor WebAssembly podporuje dopřednou kompilaci (AOT),kde můžete kompilovat kód .NET přímo do WebAssembly. Kompilace AOT vede ke zlepšení výkonu modulu runtime na úkor větší velikosti aplikace.

Bez povolení kompilace AOT běží aplikace v prohlížeči pomocí Blazor WebAssembly překladače .NET Intermediate Language (IL), který je implementovaný ve WebAssembly. Vzhledem k tomu, že je kód .NET interpretován, aplikace jsou obvykle pomalejší než v modulu runtime .NET za běhu (JIT) na straně serveru. Kompilace AOT řeší tento problém s výkonem tím, že kompiluje kód .NET aplikace přímo do WebAssembly pro nativní spuštění WebAssembly prohlížečem. Vylepšení výkonu AOT může přinést výrazné vylepšení pro aplikace, které spouští úlohy náročné na procesor. Nevýhodou použití kompilace AOT je, že aplikace kompilované službou AOT jsou obecně větší než jejich protějšky interpretované jazykem IL, takže jejich stažení do klienta při první vyžádání obvykle trvá déle.

Pokud chcete povolit kompilaci WebAssembly AOT, přidejte vlastnost nastavenou na do <RunAOTCompilation> true souboru projektu Blazor WebAssembly aplikace:

<PropertyGroup>
  <RunAOTCompilation>true</RunAOTCompilation>
</PropertyGroup>

Pokud chcete aplikaci zkompilovat do WebAssembly, publikujte ji. Publikováním konfigurace zajistíte, že se spustí také propojení .NET Intermediate Language (IL), které zmenšuje velikost Release publikované aplikace:

dotnet publish -c Release

Kompilace WebAssembly AOT se provádí pouze při publikování projektu. Kompilace AOT se při spuštění projektu během vývoje (prostředí) nepoužívá, protože kompilace AOT u malých projektů obvykle trvá několik minut a u větších projektů může trvat Development mnohem déle. Zkrácení doby sestavení pro kompilaci AOT je ve vývoji pro budoucí verze ASP.NET Core.

Velikost zkompilované aplikace AOT je obecně větší než velikost aplikace, pokud je zkompilována Blazor WebAssembly do .NET IL. I když rozdíl velikosti závisí na aplikaci, většina aplikací zkompilovaných službou AOT je přibližně dvojnásobná oproti verzi zkompilované il. To znamená, že použití kompilace AOT vymění výkon doby načítání za běhu. Jestli je tento kompromis vhodné použít při kompilaci AOT, závisí na vaší aplikaci. Blazor WebAssembly Kompilaci AOT obecně nejvíce využívají aplikace, které jsou náročné na procesor.

Opětovné propojení za běhu

Jednou z největších částí aplikace je modul runtime .NET založený na WebAssembly ( ), který prohlížeč musí stáhnout při prvním přístupu k aplikaci Blazor WebAssembly dotnet.wasm prohlížečem uživatele. Opětovné propojení modulu runtime .NET WebAssembly oříznutí nepoužívaného kódu modulu runtime a tím zvyšuje rychlost stahování.

Opětovné propojení za běhu se provádí automaticky při publikování aplikace. Snížení velikosti je zvlášť výrazné při zakázání globalizace. Další informace naleznete v tématu ASP.NET Core Blazor globalizace a lokalizace.

Podpora nativních závislostí

Blazor WebAssembly Aplikace mohou používat nativní závislosti vytvořené pro spuštění v WebAssembly. Nativní závislosti můžete staticky propojit s modul runtime .NET WebAssembly pomocí nástrojů sestavení .NET WebAssembly. Stejné nástroje použité k dopředné kompilaci aplikace do WebAssembly nebo k opětovnému propojení modulu runtime k odebrání nepoužívaných funkcí Blazor .

Buildovací nástroje .NET WebAssembly jsou založené na Emscripten, jazyce toolchain kompilátoru pro webovou platformu. Pokud chcete nainstalovat buildovací nástroje .NET WebAssembly, použijte některý z následujících přístupů:

• V instalačním programu služby Visual Studio komponentu.
• Spusťte dotnet workload install wasm-tools příkaz z příkazového řádku pro správu.

Přidání nativních závislostí Blazor WebAssembly do aplikace přidáním <NativeFileReference> položek do souboru projektu aplikace Když je projekt sestaven, předá se každý z nich do Emscripten pomocí sestavovacích nástrojů .NET WebAssembly, aby byly zkompilovány a <NativeFileReference> propojeny do modulu runtime. Dále do p/invoke nativního kódu z kódu .NET aplikace.

Obecně platí, že jakýkoli přenosný nativní kód lze použít jako nativní závislost s Blazor WebAssembly . Nativní závislosti můžete přidat do kódu C/C++ nebo kódu dříve zkompilovaných pomocí Emscriptenu:

• Soubory objektů ( .o )
• Archivní soubory ( .a )
• Bitcode ( .bc )
• Samostatné moduly WebAssembly ( .wasm )

Předem vytvořené závislosti se obvykle musí sestavit pomocí stejné verze Emscripten, která se používá k sestavení modulu runtime .NET WebAssembly.

Použití nativního kódu

Přidejte do aplikace jednoduchou nativní funkci jazyka Blazor WebAssembly C:

1. Vytvořte nový Blazor WebAssembly projekt.

2. Přidejte Test.c do projektu soubor .

3. Přidejte funkci jazyka C Test.c do pro výpočet faktoriály:

   int fact(int n)
   {
       if (n == 0) return 1;
       return n * fact(n - 1);
   }
   

4. Do <NativeFileReference> souboru projektu Test.c aplikace přidejte pro :

   <ItemGroup>
     <NativeFileReference Include="Test.c" />
   </ItemGroup>
   

5. V komponentě ( ) přidejte pro funkci ve vygenerované knihovně a zavolejte metodu z kódu Razor .razor DllImportAttribute fact Test fact .NET v komponentě:

   @using System.Runtime.InteropServices
   
   <p>@fact(3)</p>
   
   @code {
       [DllImport("Test")]
       static extern int fact(int n);
   }
   

Když sestavíte aplikaci s nainstalovanými nástroji sestavení .NET WebAssembly, nativní kód jazyka C se zkompiluje a prolíná s prostředím runtime .NET WebAssembly ( dotnet.wasm ). Kompilace a propojení může trvat několik minut. Po dokončení aplikace spusťte aplikaci, abyste viděli vykreslenou faktoriální hodnotu.

Použití knihoven

NuGet balíčky mohou obsahovat nativní závislosti pro použití ve WebAssembly. Tyto knihovny a jejich nativní funkce jsou pak dostupné pro libovolnou Blazor WebAssembly aplikaci. Soubory pro nativní závislosti by měly být sestaveny pro WebAssembly a zabaleny do složky specifické browser-wasm pro architekturu. Na závislosti specifické pro WebAssembly se automaticky odkazuje a musí se na ně odkazovat ručně jako na <NativeFileReference> položky. Autoři balíčků mohou přidat nativní odkazy zahrnutím souboru do balíčku .props s odkazy.

SkiaSharp je 2D grafická knihovna pro více platforem pro .NET založená na nativní grafické knihovně Skiaa teď má podporu verze Preview pro Blazor WebAssembly .

Použití SkiaSharpu v Blazor WebAssembly aplikaci:

1. Přidejte odkaz na balíček SkiaSharp.Views.Blazor v Blazor WebAssembly projektu. Pomocí Visual Studio přidejte balíčky do aplikace (Manage NuGet Packages) nebo spusťte příkaz v příkazovém dotnet add package prostředí:

   dotnet add package –-prerelease SkiaSharp.Views.Blazor
   

   Poznámka

   V době psaní tohoto článku je balíček předběžnou SkiaSharp.Views.Blazor NuGet, který není určený k použití v produkčním prostředí.

2. Přidejte SKCanvasView do aplikace komponentu následujícím způsobem:

   • SkiaSharpSkiaSharp.Views.Blazora obory názvů.
   • Logika pro kreslení v komponentě Zobrazení plátna SkiaSharp ( SKCanvasView ).

   Pages/NativeDependencyExample.razor:

   @page "/native-dependency-example"
   @using SkiaSharp
   @using SkiaSharp.Views.Blazor
   
   <PageTitle>Native dependency</PageTitle>
   
   <h1>Native dependency example with SkiaSharp</h1>
   
   <SKCanvasView OnPaintSurface="OnPaintSurface" />
   
   @code {
       private void OnPaintSurface(SKPaintSurfaceEventArgs e)
       {
           var canvas = e.Surface.Canvas;
           canvas.Clear(SKColors.White);
           using var paint = new SKPaint
           {
               Color = SKColors.Black,
               IsAntialias = true,
               TextSize = 24
           };
           canvas.DrawText("SkiaSharp", 0, 24, paint);
       }
   }
   

3. Sestavte aplikaci, což může trvat několik minut. Spusťte aplikaci a přejděte na NativeDependencyExample komponentu na /native-dependency-example adrese .

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

Přizpůsobte si způsob načítání spouštěcích prostředků pomocí rozhraní loadBootResource API. Další informace naleznete v tématu ASP.NET Core Blazor Úvod.

Komprese

Když je aplikace publikovaná, výstup se během publikování staticky komprimuje, aby se zmenšila velikost aplikace a snížila se režie Blazor WebAssembly při komprimaci za běhu. Používají se následující kompresní algoritmy:

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

Blazor spoléhá na hostitele, který bude obsluhovat příslušné komprimované soubory. Při použití ASP.NET Core hostovaného projektu je hostitelský projekt schopen vyjednávání obsahu a obsluhující staticky komprimované soubory. Při hostování samostatné aplikace může být potřeba další práce, aby se zajistilo, že se zpracují staticky Blazor WebAssembly komprimované soubory:

• Informace o web.config konfiguraci komprese služby IIS najdete v části IIS: Brotli a Komprese Gzip.

• Při hostování v řešeních pro statické hostování, která nepodporují staticky komprimované vyjednávání obsahu souboru, jako je GitHub Pages, zvažte konfiguraci aplikace tak, aby načítá a dekóduje komprimované soubory Brotli:

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

    Poznámka

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

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

    V wwwroot/index.html souboru nastavte autostart u značky na false Blazor <script> :

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

    Za Blazor značku a před <script> ukončovací značku přidejte následující blok kódu </body> <script> JavaScriptu:

    <script type="module">
      import { BrotliDecode } from './decode.min.js';
      Blazor.start({
        loadBootResource: function (type, name, defaultUri, integrity) {
          if (type !== 'dotnetjs' && location.hostname !== 'localhost') {
            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ů naleznete v tématu ASP.NET Core Blazor Úvod .

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

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

BlazorEnableCompressionVlastnost může být předána dotnet publish příkazu s následující syntaxí v příkazovém prostředí:

dotnet publish -p:BlazorEnableCompression=false

Přepište adresy URL pro správné směrování.

Požadavky směrování na součásti stránky v Blazor WebAssembly aplikaci nejsou stejně jednoduché jako požadavky směrování v Blazor Server hostované aplikaci. Vezměte v úvahu Blazor WebAssembly aplikaci se dvěma součástmi:

• Main.razor: Načte do kořenového adresáře aplikace a obsahuje odkaz na About komponentu ( href="About" ).
• About.razor: About součást.

Pokud je výchozí dokument aplikace požadován pomocí panelu Adresa prohlížeče (například https://www.contoso.com/ ):

1. Prohlížeč vytvoří požadavek.
2. Vrátí se výchozí stránka, což je obvykle index.html .
3. index.html napředá aplikaci.
4. Blazorse načte směrovač a Razor Main Komponenta se vykreslí.

Na hlavní stránce vyberte odkaz na About komponentu na klientovi, protože Blazor směrovač zastaví v prohlížeči, aby odeslal požadavek na Internet www.contoso.com pro About a sloužil přímo vykreslené About součásti. Všechny požadavky na vnitřní koncové body v Blazor WebAssembly aplikaci fungují stejným způsobem: požadavky neaktivují požadavky založené na prohlížeči na prostředky hostované na serveru na internetu. Směrovač zpracovává požadavky interně.

Pokud je žádost vytvořena pomocí panelu Adresa prohlížeče pro www.contoso.com/About , požadavek se nezdařil. Žádný takový prostředek na internetovém hostiteli aplikace neexistuje, takže se vrátí odpověď 404 – Nenalezeno .

Vzhledem k tomu, že prohlížeče připravují žádosti na internetové hostitele pro stránky na straně klienta, webové servery a hostitelské služby musí přepsat všechny požadavky na prostředky, které nejsou na stránce fyzicky na serveru index.html . Když index.html se vrátí, Blazor směrovač aplikace 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 .

Hostované nasazení s ASP.NET Core

hostované nasazení obsluhuje Blazor WebAssembly aplikaci prohlížeči z ASP.NET Core aplikace , která běží na webovém serveru.

Klientská Blazor WebAssembly aplikace se publikuje do /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot složky serverové aplikace spolu s dalšími statickými webovými prostředky serverové aplikace. Obě aplikace se nasazují dohromady. vyžaduje se webový server, který podporuje hostování aplikace ASP.NET Core. v případě hostovaného nasazení Visual Studio zahrnuje šablonu projektu Blazor WebAssembly aplikace ( blazorwasm šablona při použití dotnet new příkazu) s Hosted vybranou možností ( -ho|--hosted při použití dotnet new příkazu).

Další informace najdete v následujících článcích:

• ASP.NET Core hostování a nasazení aplikací:Hostování a nasazení ASP.NET Core
• Nasazení do Azure App Service: Publikování ASP.NET Core aplikace do Azure pomocí Visual Studio
• Blazor šablony projektu: ASP.NET Core Blazor struktura projektu

Hostované nasazení s více Blazor WebAssembly aplikacemi

Konfigurace aplikací

Hostovaná Blazor řešení můžou sloužit více Blazor WebAssembly aplikacím.

V následujícím příkladu:

• Úvodní (první) klientská aplikace je výchozí projekt klienta řešení vytvořený ze Blazor WebAssembly šablony projektu. První klientská aplikace je přístupná v prohlížeči z adresy URL /FirstApp na portu 5001 nebo s hostitelem firstapp.com .
• Do řešení se přidá druhá klientská aplikace SecondBlazorApp.Client . Druhá klientská aplikace je přístupná v prohlížeči z adresy URL /SecondApp na portu 5002 nebo s hostitelem secondapp.com .

Použijte existující hostované Blazor řešení nebo vytvořte nové řešení ze Blazor šablony hostovaného projektu:

• V souboru projektu klientské aplikace přidejte <StaticWebAssetBasePath> vlastnost do pole <PropertyGroup> s hodnotou, FirstApp abyste nastavili základní cestu pro statické prostředky projektu:

  <PropertyGroup>
    ...
    <StaticWebAssetBasePath>FirstApp</StaticWebAssetBasePath>
  </PropertyGroup>
  

• Přidání druhé klientské aplikace do řešení:

  • Přidejte do složky řešení složku s názvem SecondClient . Složka řešení vytvořená v šabloně projektu obsahuje následující soubor řešení a složky po SecondClient Přidání složky:

    • Client složky
    • SecondClient složky
    • Server složky
    • Shared složky
    • {SOLUTION NAME}.sln souborů

    Zástupný symbol {SOLUTION NAME} je název řešení.

  • Vytvořte Blazor WebAssembly aplikaci s názvem SecondBlazorApp.Client ve SecondClient složce ze Blazor WebAssembly šablony projektu.

  • V SecondBlazorApp.Client souboru projektu aplikace:

    • Přidejte <StaticWebAssetBasePath> vlastnost do pole <PropertyGroup> s hodnotou SecondApp :

      <PropertyGroup>
        ...
        <StaticWebAssetBasePath>SecondApp</StaticWebAssetBasePath>
      </PropertyGroup>
      

    • Přidat odkaz na projekt do Shared projektu:

      <ItemGroup>
        <ProjectReference Include="..\Shared\{SOLUTION NAME}.Shared.csproj" />
      </ItemGroup>
      

      Zástupný symbol {SOLUTION NAME} je název řešení.

• V souboru projektu aplikace serveru vytvořte odkaz na projekt pro přidanou SecondBlazorApp.Client klientskou aplikaci:

  <ItemGroup>
    <ProjectReference Include="..\Client\{SOLUTION NAME}.Client.csproj" />
    <ProjectReference Include="..\SecondClient\SecondBlazorApp.Client.csproj" />
    <ProjectReference Include="..\Shared\{SOLUTION NAME}.Shared.csproj" />
  </ItemGroup>
  

  Zástupný symbol {SOLUTION NAME} je název řešení.

• V souboru serverové aplikace Properties/launchSettings.json Nakonfigurujte applicationUrl Kestrel profil ( {SOLUTION NAME}.Server ) pro přístup k klientským aplikacím na portech 5001 a 5002:

  "applicationUrl": "https://localhost:5001;https://localhost:5002",
  

• V souboru serverové aplikace Program.cs odeberte následující řádky, které se zobrazí po volání UseHttpsRedirection :

  -app.UseBlazorFrameworkFiles();
  -app.UseStaticFiles();
  
  -app.UseRouting();
  
  -app.MapRazorPages();
  -app.MapControllers();
  -app.MapFallbackToFile("index.html");
  

  Přidejte middleware, který mapuje požadavky na klientské aplikace. Následující příklad konfiguruje middleware ke spuštění v následujících případech:

  • Port žádosti je buď 5001 pro původní klientskou aplikaci, nebo 5002 pro přidanou klientskou aplikaci.

  • Hostitel žádosti je buď firstapp.com pro původní klientskou aplikaci, nebo secondapp.com pro přidanou klientskou aplikaci.

    Poznámka

    Příklad uvedený v této části vyžaduje další konfiguraci pro:

    • Přístup k aplikacím v ukázkových doménách hostitelů firstapp.com a secondapp.com .
    • Certifikáty pro klientské aplikace, které umožňují zabezpečení TLS (HTTPS).

    Požadovaná konfigurace překračuje rozsah tohoto článku a závisí na tom, jak je řešení hostované. Další informace najdete v článcích o hostiteli a nasazení.

  Vložte následující kód, kde byly řádky odebrány dříve:

  app.MapWhen(ctx => ctx.Request.Host.Port == 5001 || 
      ctx.Request.Host.Equals("firstapp.com"), first =>
  {
      first.Use((ctx, nxt) =>
      {
          ctx.Request.Path = "/FirstApp" + ctx.Request.Path;
          return nxt();
      });
  
      first.UseBlazorFrameworkFiles("/FirstApp");
      first.UseStaticFiles();
      first.UseStaticFiles("/FirstApp");
      first.UseRouting();
  
      first.UseEndpoints(endpoints =>
      {
          endpoints.MapControllers();
          endpoints.MapFallbackToFile("/FirstApp/{*path:nonfile}", 
              "FirstApp/index.html");
      });
  });
  
  app.MapWhen(ctx => ctx.Request.Host.Port == 5002 || 
      ctx.Request.Host.Equals("secondapp.com"), second =>
  {
      second.Use((ctx, nxt) =>
      {
          ctx.Request.Path = "/SecondApp" + ctx.Request.Path;
          return nxt();
      });
  
      second.UseBlazorFrameworkFiles("/SecondApp");
      second.UseStaticFiles();
      second.UseStaticFiles("/SecondApp");
      second.UseRouting();
  
      second.UseEndpoints(endpoints =>
      {
          endpoints.MapControllers();
          endpoints.MapFallbackToFile("/SecondApp/{*path:nonfile}", 
              "SecondApp/index.html");
      });
  });
  

  Další informace o UseStaticFiles naleznete v tématu BlazorASP.NET Core statické soubory .

  Další informace o UseBlazorFrameworkFiles a MapFallbackToFile najdete v následujících zdrojích informací:

  • Microsoft.AspNetCore.Builder.ComponentsWebAssemblyApplicationBuilderExtensions.UseBlazorFrameworkFiles (odkazový zdroj)
  • Microsoft.AspNetCore.Builder.StaticFilesEndpointRouteBuilderExtensions.MapFallbackToFile (odkazový zdroj)

  Poznámka

  dokumentace odkazuje na zdrojový odkaz na ASP.NET Core načtení main větve úložiště, která představuje aktuální vývoj jednotky produktu pro další verzi ASP.NET Core. Pokud chcete vybrat větev pro jinou verzi, vyberte ji pomocí rozevíracího seznamu větve přepínače nebo značky . vyberte například release/5.0 větev pro verzi ASP.NET Core 5,0.

• V řadiči pro předpověď počasí aplikace serveru ( Controllers/WeatherForecastController.cs ) nahraďte stávající trasu ( [Route("[controller]")] ) následujícími trasami WeatherForecastController :

  [Route("FirstApp/[controller]")]
  [Route("SecondApp/[controller]")]
  

  Middleware přidaný do kanálu zpracování požadavků serverové aplikace dříve upravuje příchozí požadavky na /WeatherForecast buď /FirstApp/WeatherForecast nebo /SecondApp/WeatherForecast v závislosti na portu (5001/5002) nebo doméně ( firstapp.com / secondapp.com ). Aby bylo možné vracet údaje o počasí z aplikace serveru do klientských aplikací, je nutné, aby byly předchozí trasy řadiče.

Statické prostředky a knihovny tříd pro více Blazor WebAssembly aplikací

K odkazování statických prostředků použijte následující přístupy:

• Pokud je prostředek ve složce klientské aplikace wwwroot , zadejte cestu normálně:

  <img alt="..." src="/{PATH AND FILE NAME}" />
  

  {PATH AND FILE NAME}Zástupný symbol je cesta a název souboru v části wwwroot .

• Pokud je Asset ve wwwroot složce Razor knihovny tříd (RCL), odkazujte na statický prostředek v klientské aplikaci podle pokynů v Opakovaně použitelné Razor uživatelské rozhraní v knihovnách tříd pomocí ASP.NET Core :

  <img alt="..." src="_content/{PACKAGE ID}/{PATH AND FILE NAME}" />
  

  {PACKAGE ID}Zástupný symbol je ID balíčkuknihovny. V případě, že <PackageId> v souboru projektu není zadán název balíčku, je výchozím názvem sestavení projektu. {PATH AND FILE NAME}Zástupný symbol je cesta a název souboru v rámci wwwroot .

Další informace o RCLs najdete v tématech:

• využívání Razor komponent ASP.NET Core z Razor knihoven tříd
• Opakovaně použitelné Razor uživatelské rozhraní v knihovnách tříd pomocí ASP.NET Core

Samostatné nasazení

Samostatné nasazení obsluhuje Blazor WebAssembly aplikaci jako sadu statických souborů, které jsou požadovány přímo klienty. Každý statický souborový server může Blazor aplikaci zpracovat.

Samostatné prostředky nasazení jsou publikovány do /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot složky.

Azure App Service

Blazor WebAssemblyaplikace se dají nasadit do Azure App Services v Windows, která hostuje aplikaci ve službě IIS.

Nasazení samostatné Blazor WebAssembly aplikace do Azure App Service pro Linux není aktuálně podporováno. Image serveru pro Linux, která je hostitelem aplikace, není v tuto chvíli k dispozici. Pro povolení tohoto scénáře probíhá práce.

Statická webová aplikace Azure

Další informace najdete v tématu kurz: sestavení statické webové aplikace Blazor ve službě Azure static Web Apps.

IIS

Služba IIS je schopným statickým souborovým serverem pro Blazor aplikace. Chcete-li nakonfigurovat službu IIS na hostování Blazor , přečtěte si téma vytvoření statického webu ve službě IIS.

Publikované assety se vytvoří ve /bin/Release/{TARGET FRAMEWORK}/publish složce. Hostovat obsah publish složky na webovém serveru nebo v hostitelské službě.

web.config

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

• typy MIME
• Pro následující typy MIME je povolena komprese protokolu HTTP:
  • application/octet-stream
  • application/wasm
• Pravidla pro přepis adres URL jsou navázána:
  • Slouží jako podadresáře, kde se nachází statické prostředky aplikace ( wwwroot/{PATH REQUESTED} ).
  • Vytvořte záložní záložní postup, aby se požadavky na nesouborové prostředky přesměrovaly do výchozího dokumentu aplikace ve složce static assets ( wwwroot/index.html ).

Použití vlastního web.config

Chcete-li použít vlastní web.config soubor, umístěte vlastní web.config soubor do kořenové složky projektu. Konfigurace projektu pro publikování prostředků specifických pro službu IIS pomocí PublishIISAssets v souboru projektu aplikace a publikování projektu:

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

Instalace modulu URL pro přepis

Pro přepis adres URL je vyžadován modul URL Rewrite . Modul není nainstalován ve výchozím nastavení a není k dispozici pro instalaci jako funkci služby role Webový server (IIS). Modul se musí stáhnout z webu IIS. K instalaci modulu použijte instalační program webové platformy:

1. Místně přejděte na stránku ke stažení modulu pro přepsání adresy URL. V případě anglické verze vyberte WebPI a Stáhněte si instalační program WebPI. Pro jiné jazyky 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 nainstalovat a přijměte licenční podmínky. Po dokončení instalace není restartování serveru vyžadováno.

Konfigurace webu

Nastavte fyzickou cestu webu na složku aplikace. Složka obsahuje:

• web.configSoubor, 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 prostředků 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 tak, že do <handlers> <system.webServer> části souboru přidáte oddíl:

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

• Zakažte dědění kořenového oddílu (nadřazené) aplikace <system.webServer> pomocí <location> elementu s inheritInChildApplications nastavením 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ědění kořenového oddílu (nadřazené) aplikace <system.webServer> je výchozí konfigurací 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 index.html souboru aplikace na alias služby IIS, který se používá při konfiguraci dílčí aplikace v IIS.

Komprese Brotli a gzip

tato část se vztahuje jenom na samostatné Blazor WebAssembly aplikace. hostované Blazor aplikace používají výchozí soubor ASP.NET Core aplikace web.config , ne soubor propojený v této části.

Službu IIS je možné nakonfigurovat prostřednictvím web.config pro poskytování komprimovaných prostředků Brotli nebo gzip Blazor pro samostatné Blazor WebAssembly aplikace. Příklad konfiguračního souboru naleznete v tématu web.config .

Další konfigurace ukázkového web.config souboru se může vyžadovat v následujících scénářích:

• Specifikace aplikace pro jednu z následujících volání:
  • Obsluha komprimovaných souborů, které nejsou konfigurovány 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í nastavení služby IIS na úrovni serveru. V závislosti na konfiguraci na úrovni serveru může aplikace vyžadovat odlišnou konfiguraci služby IIS, než jakou web.config obsahuje ukázkový soubor.

Řešení potíží

Pokud dojde k chybě 500 – interní chyba serveru a správce služby IIS vyvolá chyby při pokusu o přístup ke konfiguraci webu, potvrďte, že je nainstalován modul URL pro přepis. Pokud modul není nainstalován, web.config soubor nelze analyzovat službou IIS. Tím se zabrání tomu, aby správce služby IIS načetl konfiguraci webu a web ze Blazor statických souborů obsluhy.

Další informace o řešení potíží s nasazeními služby IIS najdete v tématu Řešení ASP.NET Core potíží s Azure App Service a službou IIS .

Azure Storage

hostování statického souboru Azure Storage umožňuje Blazor hostování aplikací bez serveru. podporují se názvy vlastních domén, Content Delivery Network Azure (CDN) a HTTPS.

Když je u služby BLOB Service povolené hostování statických webů v účtu úložiště:

• Nastavte název dokumentu indexu na index.html .
• Nastavte cestu k chybovému dokumentu na index.html . Razor součásti a jiné koncové body, které nejsou v souboru, se neukládají na fyzických cestách ve statickém obsahu uloženém službou BLOB Service. Když se přijme žádost o jeden z těchto prostředků, kterou Blazor by měl směrovač zpracovat, chyba 404 – nenalezená služba BLOB Service směruje požadavek na cestu k chybovému dokumentu. index.htmlVrátí se objekt BLOB a Blazor směrovač načte a zpracuje cestu.

Pokud nejsou za běhu načteny soubory z důvodu nevhodných typů MIME v Content-Type hlavičkách souborů, 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).

• Změňte typy MIME ( Content-Type hlavičky) souborů po nasazení aplikace.

  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 klikněte na tlačítko Uložit .

Další informace najdete v tématu statické hostování webů v Azure Storage.

Nginx

Následující nginx.conf soubor je zjednodušený a ukazuje, jak nakonfigurovat Nginx pro odeslání index.html souboru pokaždé, když 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 přenosové rychlosti Nginx pomocí můžou limit_req Blazor WebAssembly aplikace vyžadovat velkou burst hodnotu parametru, aby odpovídala poměrně velkému počtu požadavků, které aplikace vytvořila. Zpočátku nastavte hodnotu aspoň 60:

http {
    server {
        ...

        location / {
            ...

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

Zvyšte hodnotu, pokud nástroje pro vývojáře v prohlížeči nebo síťový provoz označují, že žádosti dostávají stavový kód Nedostupnosti 503-Service .

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

Apache

Nasazení Blazor WebAssembly aplikace na CentOS 7 nebo novější:

1. Vytvořte konfigurační soubor Apache. V následujícím příkladu 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
       AddType application/octet-stream .dll
   
       <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>
   

2. Soubor konfigurace Apache umístěte do /etc/httpd/conf.d/ adresáře, který je výchozím adresářem konfigurace Apache v CentOS 7.

3. Umístěte soubory aplikace do /var/www/blazorapp adresáře (umístění zadaného do DocumentRoot konfiguračního souboru).

4. Restartujte službu Apache.

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

Stránky GitHubu

Chcete-li zpracovat přepisy 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 tématu úložiště SteveSandersonMS/ Blazor OnGitHubPages GitHub:

• wwwroot/404.html
• Živý web)

Při použití webu projektu namísto webu organizace aktualizujte <base> značku v wwwroot/index.html . nastavte href hodnotu atributu na GitHub název úložiště s koncovým lomítkem (například /my-repository/ ). v úložišti SteveSandersonMS/ Blazor OnGitHubPages GitHubse základ href aktualizuje při publikování pomocí .github/workflows/main.yml konfiguračního souboru.

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

--contentrootArgument nastavuje absolutní cestu k adresáři, který obsahuje soubory obsahu aplikace (kořen obsahu). V následujících příkladech /content-root-path je kořenová cesta obsahu aplikace.

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

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

• přidejte položku do launchSettings.json souboru aplikace v profilu IIS Express . Toto nastavení se používá, když se aplikace spustí s Visual Studio Debugger a z příkazového řádku pomocí dotnet run .

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

• V Visual Studio zadejte argument v části Vlastnosti > – ladění > argumentů aplikace. Nastavení argumentu na Visual Studio vlastností přidá argument do launchSettings.json souboru.

  --contentroot=/content-root-path
  

Základ cesty

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

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

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

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

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

• V Visual Studio zadejte argument v části Vlastnosti > – ladění > argumentů aplikace. Nastavení argumentu na Visual Studio vlastností přidá argument do launchSettings.json souboru.

  --pathbase=/relative-URL-path
  

Adresy URL

Argument nastaví IP adresy nebo adresy hostitelů s porty a protokoly, na --urls které se mají naslouchat požadavkům.

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

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

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

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

• V Visual Studio zadejte argument v části Vlastnosti > – ladění > argumentů aplikace. Nastavení argumentu na Visual Studio vlastností přidá argument do launchSettings.json souboru.

  --urls=http://127.0.0.1:0
  

Konfigurace ořezávání

Blazor provádí ořezávání jazyka IL (Intermediate Language) u každého sestavení verze, aby se odebírat nepotřebné il z výstupních sestavení. Další informace naleznete v tématu Konfigurace oříznutého ASP.NET Core Blazor.

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

Pokud potřebujete změnit přípony názvů souborů publikovaných souborů aplikace, postupujte podle .dll pokynů v této části.

Po publikování aplikace pomocí skriptu prostředí nebo DevOps buildu přejmenujte soubory tak, aby se .dll používá jiná přípona souboru. .dllZacílit soubory wwwroot v adresáři publikovaného výstupu aplikace (například {CONTENT ROOT}/bin/Release/netstandard2.1/publish/wwwroot ).

V následujících příkladech .dll jsou soubory přejmenovány tak, aby se používá .bin přípona souboru.

Ve Windows:

dir .\_framework\_bin | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content .\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content .\_framework\blazor.boot.json

Pokud se používají také prostředky pracovního procesu služby, přidejte následující příkaz:

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

V Linuxu nebo macOS:

for f in _framework/_bin/*; do mv "$f" "`echo $f | sed -e 's/\.dll/.bin/g'`"; done
sed -i 's/\.dll"/.bin"/g' _framework/blazor.boot.json

Pokud se používají také prostředky pracovního procesu služby, přidejte následující příkaz:

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

Pokud chcete použít jinou příponu souboru než .bin , .bin nahraďte v předchozích příkazech .

Pokud chcete komprimované blazor.boot.json.gz soubory blazor.boot.json.br a řešit, přistupte k jednomu z následujících přístupů:

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

Předchozí pokyny platí také v případě, že se používají prostředky pracovního procesu služby. Odeberte nebo znovu dekomprimujte wwwroot/service-worker-assets.js.br a wwwroot/service-worker-assets.js.gz . Jinak kontroly integrity souborů v prohlížeči selžou.

Následující Windows používá skript PowerShellu umístěný v kořenovém adresáři projektu.

ChangeDLLExtensions.ps1::

param([string]$filepath,[string]$tfm)
dir $filepath\bin\Release\$tfm\wwwroot\_framework\_bin | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content $filepath\bin\Release\$tfm\wwwroot\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\wwwroot\_framework\blazor.boot.json
Remove-Item $filepath\bin\Release\$tfm\wwwroot\_framework\blazor.boot.json.gz

Pokud se používají také prostředky pracovního procesu služby, přidejte následující příkaz:

((Get-Content $filepath\bin\Release\$tfm\wwwroot\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\wwwroot\service-worker-assets.js

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

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

Řešení selhání kontroly integrity

Při stahování spouštěcích souborů aplikace instruuje prohlížeč, aby u odpovědí Blazor WebAssembly prováděl kontroly integrity. Používá informace v souboru blazor.boot.json k určení očekávaných hodnot hash SHA-256 .dll pro , a další .wasm soubory. To je užitečné z následujících důvodů:

• Zajišťuje, že ne riskujete načtení nekonzistentní sady souborů, například pokud se na webový server použije nové nasazení, zatímco uživatel stahuje soubory aplikace. Nekonzistentní soubory mohou vést k nedefinovanému chování.
• Zajišťuje, že prohlížeč uživatele nikdy neuchová v mezipaměti nekonzistentní nebo neplatné odpovědi, což by mohlo bránit v spuštění aplikace, i když stránku ručně aktualizují.
• Díky tomu je bezpečné ukládat odpovědi do mezipaměti, a dokonce ani kontrolovat změny na straně serveru, dokud se nezmění očekávané hash SHA-256, takže další načtení stránky zahrnuje méně požadavků a dokončení je mnohem rychlejší.

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

Nepodařilo se najít platnou hodnotu hash v atributu integrity pro prostředekApp.dll s vypočítanou integritou https://myapp.example.com/\_framework/My Blazor SHA-256 IIa70iwvmEg5WiDV17OpQ5e DigesttNYqL186J56852RpJY=. Prostředek se zablokoval.

Ve většině případů to není problém se samotnou kontrolou integrity. Místo toho to znamená, že existuje nějaký jiný problém a kontrola integrity vás na tento jiný problém upozorní.

Diagnostika problémů s integritou

Vygenerovaný manifest po sestavení aplikace popisuje hash SHA-256 vašich spouštěcích prostředků (například , a dalších souborů) v době vytváření výstupu blazor.boot.json .dll .wasm sestavení. Kontrola integrity projde tak dlouho, dokud se v souboru hash SHA-256 shodují blazor.boot.json soubory doručované do prohlížeče.

Mezi běžné důvody, proč k selhání dojde, jsou:

• Odpověď webového serveru je chyba (například 404 – Nenasaže se nebo 500 – Vnitřní chyba serveru) místo souboru, který prohlížeč požaduje. Prohlížeč to 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. K tomu může dojít:
  • Pokud ručně upravíte výstup sestavení nebo sestavíte nástroje.
  • 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 Pokud potvrdíte soubory v systému Windows a zkontrolujete je v Linuxu, Git transparentně převede koncové čáry stylu Windows na koncové čáry unixového stylu. Změna konce řádků souboru změní hash SHA-256. Pokud se chcete tomuto problému vyhnout, zvažte použití pro zacházení s .gitattributes artefakty sestavení jako se binary soubory.
  • Webový server upraví obsah souboru v rámci jejich obsluhu. Některé distribuční sítě obsahu (CDN) se například automaticky pokoušejí o minifikaci KÓDU HTML, a tím ho upravují. Tyto funkce možná budete muset zakázat.

Pokud chcete diagnostikovat, které z těchto případů platí:

1. Všimněte si, který soubor aktivuje chybu přečtením chybové zprávy.
2. Otevřete vývojářské nástroje v prohlížeči a podívejte se na kartu Síť. V případě potřeby stránku znovu načtěte, abyste viděli seznam požadavků a odpovědí. V tomto seznamu vyhledejte soubor, který spouští chybu.
3. Zkontrolujte stavový kód HTTP v odpovědi. Pokud server vrátí něco jiného než 200 – OK (nebo jiný stavový kód 2xx), musíte diagnostikovat problém na straně serveru. Například stavový kód 403 znamená, že došlo k problému s autorizací, zatímco stavový kód 500 znamená, že server selhává neurčeným způsobem. Při diagnostice a opravě aplikace se obraťte na protokoly na straně serveru.
4. Pokud je stavový kód prostředku 200 – OK, podívejte se na obsah odpovědi ve vývojářských nástrojích prohlížeče a zkontrolujte, jestli se obsah shoduje s očekávanými daty. Běžným problémem je například chybná konfigurace směrování tak, aby požadavky vrátily index.html vaše data i pro jiné soubory. Ujistěte se, že odpovědi na požadavky jsou binární soubory WebAssembly a že odpovědi na požadavky jsou binární soubory sestavení .wasm .dll .NET. Pokud ne, máte problém se směrováním na straně serveru, který je možné diagnostikovat.
5. Pomocí skriptu PowerShellupro řešení potíží s integritou vyhledejte ověřený a nasazený výstup aplikace.

Pokud potvrdíte, že server vrací viditelně správná data, mezi sestavením a doručením souboru musí být mezi sestavením a doručením souboru něco jiného. Pokud chcete tento problém prozkoumat:

• Prozkoumejte soubor nástrojů sestavení a mechanismus nasazení pro případ, že po sestavení souborů upraví soubory. Příkladem je, když Git transformuje konce řádků souboru, jak je popsáno výše.
• Zkontrolujte webový server nebo CDN pro případ, že jsou nastavené tak, aby dynamicky upravují odpovědi (například se pokouší minify HTML). Je v pořádku, když webový server implementuje kompresi HTTP (například vrácení nebo ), protože to nemá vliv na výsledek po content-encoding: br content-encoding: gzip dekompresi. Není ale v pořádku, aby webový server upravoval nekomprimovaná data.

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

Pomocí skriptu integrity.ps1 PowerShellu ověřte publikovanou a nasazenou Blazor aplikaci. Skript je k dispozici pro PowerShell Core 6 jako výchozí bod, když má aplikace problémy s integritou, které rozhraní Blazor nemůže identifikovat. Vlastní nastavení skriptu může být pro vaše aplikace potřeba, včetně toho, jestli běží ve verzi PowerShellu novější než 6.2.7.

Skript zkontroluje soubory ve složce a stáhne je z nasazené aplikace, aby detekoval problémy v různých manifestech obsahujících publish 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ě nasazena do cíle nasazení nebo se v prostředí cíle nasazení něco změnilo.
• Mezi nasazenou aplikací a výstupem publikování aplikace jsou rozdíly.

Vyvolat skript pomocí následujícího příkazu v příkazovém prostředí PowerShellu:

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

Zástupných symbolů:

• {BASE URL}: Adresa URL nasazené aplikace.
• {PUBLISH OUTPUT FOLDER}: Cesta ke složce nebo umístění publish aplikace, 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 aplikací, které nejsou PWA

Ve většině případů nezakažte kontrolu integrity. Zakázáním kontroly integrity se nevyřeší základní problém, který způsobil neočekávané odpovědi, a tím se ztratí výhody uvedené výše.

Mohou se zobrazit případy, kdy se webový server nemůže spoléhat na vracení konzistentních odpovědí a vy nemáte na výběr, ale zakážete kontroly integrity. Pokud chcete kontroly integrity zakázat, přidejte do skupiny vlastností v souboru Blazor WebAssembly .csproj projektu následující:

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResources také zakáže výchozí chování ukládání souborů , a do mezipaměti na základě jejich hodnot hash SHA-256, protože vlastnost indikuje, že hodnoty hash Blazor .dll SHA-256 nelze kvůli správnosti .wasm spoléhat. I s tímto nastavením 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 hlavičkách, které cache-control slouží.

Zákaz kontroly integrity pro PWA

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

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

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

Pokud chcete kontrolu integrity zakázat, odeberte integrity parametr tak, že změníte řádek na následující:

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

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

S Blazor WebAssembly modelem hostování:

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

Podporují se následující strategie nasazení:

• Aplikaci Blazor obsluhou používá ASP.NET Core aplikace. Tato strategie je ována v části Hostované nasazení s ASP.NET Core.
• Aplikace Blazor je umístěná na statickém hostování webového serveru nebo služby, kde se .NET k obsluhu aplikace Blazor nepouží. Tato strategie je probádá v části Samostatné nasazení, která obsahuje informace o hostování aplikace jako Blazor WebAssembly dílčí aplikace služby IIS.

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

Přizpůsobte si způsob načítání spouštěcích prostředků pomocí rozhraní loadBootResource API. Další informace naleznete v tématu ASP.NET Core Blazor Úvod.

Komprese

Při publikování aplikace se výstup staticky komprimuje během publikování, aby se zmenšila velikost aplikace a snížila se režie Blazor WebAssembly komprese za běhu. Používají se následující kompresní algoritmy:

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

Blazor spoléhá na hostitele, který bude obsluhovat příslušné komprimované soubory. Při použití ASP.NET Core hostovaného projektu je hostitelský projekt schopen vyjednávání obsahu a obsluhující staticky komprimované soubory. Při hostování samostatné aplikace může být potřeba další práce, aby se zajistilo, že se zpracují staticky Blazor WebAssembly komprimované soubory:

• Informace o web.config konfiguraci komprese služby IIS najdete v části IIS: Brotli a Komprese Gzip.

• Při hostování v řešeních pro statické hostování, která nepodporují staticky komprimované vyjednávání obsahu souboru, jako je GitHub Pages, zvažte konfiguraci aplikace tak, aby načítá a dekóduje komprimované soubory Brotli:

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

    Poznámka

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

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

    V wwwroot/index.html souboru nastavte autostart na hodnotu u značky false Blazor <script> :

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

    Za Blazor značku a před <script> ukončovací značku přidejte následující blok kódu </body> <script> JavaScriptu:

    <script type="module">
      import { BrotliDecode } from './decode.min.js';
      Blazor.start({
        loadBootResource: function (type, name, defaultUri, integrity) {
          if (type !== 'dotnetjs' && location.hostname !== 'localhost') {
            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 Úvod .

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

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

Vlastnost BlazorEnableCompression lze předat do příkazu s následující dotnet publish syntaxí v příkazovém prostředí:

dotnet publish -p:BlazorEnableCompression=false

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

Směrování požadavků na součásti stránky v aplikaci není tak jednoduché jako Blazor WebAssembly směrování požadavků v Blazor Server hostované aplikaci. Představte si Blazor WebAssembly aplikaci se dvěma komponentami:

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

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

1. Prohlížeč vytvoří požadavek.
2. Vrátí se výchozí stránka, což je obvykle index.html .
3. index.html bootstraps the app.
4. Blazorse načítá směrovač Razor Main a komponenta se vykreslí.

Na hlavní stránce funguje výběr odkazu na komponentu na klientovi, protože směrovač zastaví v prohlížeči požadavek na internet na a zobrazí samotnou About Blazor www.contoso.com About vykreslenou About komponentu. Všechny požadavky na interní Blazor WebAssembly koncové body v rámci aplikace fungují stejným způsobem: Požadavky nespouštějí požadavky založené na prohlížeči na prostředky hostované na serveru na internetu. Směrovač zpracovává požadavky interně.

Pokud je požadavek proveden pomocí adresního řádku prohlížeče pro www.contoso.com/About , požadavek se nezdaří. Žádný takový prostředek na internetovém hostiteli aplikace neexistuje, takže se vrátí odpověď 404 – Nenalézá se.

Vzhledem k tomu, že prohlížeče zažádají internetové hostitele o 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ánku. Jakmile se vrátí, směrovač aplikace převezme služby a odpoví index.html Blazor správným zdrojem.

Při nasazování na server služby IIS můžete použít modul přepisování adres URL s publikovaným souborem web.config aplikace. Další informace najdete v části IIS.

Hostované nasazení s ASP.NET Core

Hostované nasazení slouží Blazor WebAssembly aplikaci do prohlížečů z ASP.NET Core, která běží na webovém serveru.

Klientská aplikace se publikuje do složky serverové aplikace spolu s dalšími statickými webovými prostředky Blazor WebAssembly /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot serverové aplikace. Tyto dvě aplikace se nasadí společně. Webový server, který je schopný hostovat ASP.NET Core aplikace. V případě hostovaného nasazení Visual Studio šablona projektu Blazor WebAssembly aplikace (šablona při použití příkazu) s vybranou možností blazorwasm ( při použití příkazu dotnet new Hosted -ho|--hosted dotnet new ).

Další informace najdete v následujících článcích:

• ASP.NET Core a nasazení aplikací:Hostování a nasazení ASP.NET Core
• Nasazení do Azure App Service: Publikování ASP.NET Core aplikace do Azure pomocí Visual Studio
• Blazor šablony projektu: ASP.NET Core Blazor struktura projektu

Hostované nasazení s více Blazor WebAssembly aplikacemi

Konfigurace aplikací

Hostovaná Blazor řešení můžou sloužit více Blazor WebAssembly aplikacím.

V následujícím příkladu:

• Úvodní (první) klientská aplikace je výchozí projekt klienta řešení vytvořený ze Blazor WebAssembly šablony projektu. První klientská aplikace je přístupná v prohlížeči z adresy URL /FirstApp na portu 5001 nebo s hostitelem firstapp.com .
• Do řešení se přidá druhá klientská aplikace SecondBlazorApp.Client . Druhá klientská aplikace je přístupná v prohlížeči z adresy URL /SecondApp na portu 5002 nebo s hostitelem secondapp.com .

Použijte existující hostované Blazor řešení nebo vytvořte nové řešení ze Blazor šablony hostovaného projektu:

• V souboru projektu klientské aplikace přidejte <StaticWebAssetBasePath> vlastnost do pole <PropertyGroup> s hodnotou, FirstApp abyste nastavili základní cestu pro statické prostředky projektu:

  <PropertyGroup>
    ...
    <StaticWebAssetBasePath>FirstApp</StaticWebAssetBasePath>
  </PropertyGroup>
  

• Přidání druhé klientské aplikace do řešení:

  • Přidejte do složky řešení složku s názvem SecondClient . Složka řešení vytvořená v šabloně projektu obsahuje následující soubor řešení a složky po SecondClient Přidání složky:

    • Client složky
    • SecondClient složky
    • Server složky
    • Shared složky
    • {SOLUTION NAME}.sln souborů

    Zástupný symbol {SOLUTION NAME} je název řešení.

  • Vytvořte Blazor WebAssembly aplikaci s názvem SecondBlazorApp.Client ve SecondClient složce ze Blazor WebAssembly šablony projektu.

  • V SecondBlazorApp.Client souboru projektu aplikace:

    • Přidejte <StaticWebAssetBasePath> vlastnost do pole <PropertyGroup> s hodnotou SecondApp :

      <PropertyGroup>
        ...
        <StaticWebAssetBasePath>SecondApp</StaticWebAssetBasePath>
      </PropertyGroup>
      

    • Přidat odkaz na projekt do Shared projektu:

      <ItemGroup>
        <ProjectReference Include="..\Shared\{SOLUTION NAME}.Shared.csproj" />
      </ItemGroup>
      

      Zástupný symbol {SOLUTION NAME} je název řešení.

• V souboru projektu aplikace serveru vytvořte odkaz na projekt pro přidanou SecondBlazorApp.Client klientskou aplikaci:

  <ItemGroup>
    <ProjectReference Include="..\Client\{SOLUTION NAME}.Client.csproj" />
    <ProjectReference Include="..\SecondClient\SecondBlazorApp.Client.csproj" />
    <ProjectReference Include="..\Shared\{SOLUTION NAME}.Shared.csproj" />
  </ItemGroup>
  

  Zástupný symbol {SOLUTION NAME} je název řešení.

• V souboru serverové aplikace Properties/launchSettings.json Nakonfigurujte applicationUrl Kestrel profil ( {SOLUTION NAME}.Server ) pro přístup k klientským aplikacím na portech 5001 a 5002:

  "applicationUrl": "https://localhost:5001;https://localhost:5002",
  

• V metodě serverové aplikace Startup.Configure ( Startup.cs ) odeberte následující řádky, které se zobrazí po volání UseHttpsRedirection :

  -app.UseBlazorFrameworkFiles();
  -app.UseStaticFiles();
  
  -app.UseRouting();
  
  -app.UseEndpoints(endpoints =>
  -{
  -    endpoints.MapRazorPages();
  -    endpoints.MapControllers();
  -    endpoints.MapFallbackToFile("index.html");
  -});
  

  Přidejte middleware, který mapuje požadavky na klientské aplikace. Následující příklad konfiguruje middleware ke spuštění v následujících případech:

  • Port žádosti je buď 5001 pro původní klientskou aplikaci, nebo 5002 pro přidanou klientskou aplikaci.

  • Hostitel žádosti je buď firstapp.com pro původní klientskou aplikaci, nebo secondapp.com pro přidanou klientskou aplikaci.

    Poznámka

    Příklad uvedený v této části vyžaduje další konfiguraci pro:

    • Přístup k aplikacím v ukázkových doménách hostitelů firstapp.com a secondapp.com .
    • Certifikáty pro klientské aplikace, které umožňují zabezpečení TLS (HTTPS).

    Požadovaná konfigurace překračuje rozsah tohoto článku a závisí na tom, jak je řešení hostované. Další informace najdete v článcích o hostiteli a nasazení.

  Vložte následující kód, kde byly řádky odebrány dříve:

  app.MapWhen(ctx => ctx.Request.Host.Port == 5001 || 
      ctx.Request.Host.Equals("firstapp.com"), first =>
  {
      first.Use((ctx, nxt) =>
      {
          ctx.Request.Path = "/FirstApp" + ctx.Request.Path;
          return nxt();
      });
  
      first.UseBlazorFrameworkFiles("/FirstApp");
      first.UseStaticFiles();
      first.UseStaticFiles("/FirstApp");
      first.UseRouting();
  
      first.UseEndpoints(endpoints =>
      {
          endpoints.MapControllers();
          endpoints.MapFallbackToFile("/FirstApp/{*path:nonfile}", 
              "FirstApp/index.html");
      });
  });
  
  app.MapWhen(ctx => ctx.Request.Host.Port == 5002 || 
      ctx.Request.Host.Equals("secondapp.com"), second =>
  {
      second.Use((ctx, nxt) =>
      {
          ctx.Request.Path = "/SecondApp" + ctx.Request.Path;
          return nxt();
      });
  
      second.UseBlazorFrameworkFiles("/SecondApp");
      second.UseStaticFiles();
      second.UseStaticFiles("/SecondApp");
      second.UseRouting();
  
      second.UseEndpoints(endpoints =>
      {
          endpoints.MapControllers();
          endpoints.MapFallbackToFile("/SecondApp/{*path:nonfile}", 
              "SecondApp/index.html");
      });
  });
  

  Další informace o UseStaticFiles naleznete v tématu BlazorASP.NET Core statické soubory .

  Další informace o UseBlazorFrameworkFiles a MapFallbackToFile najdete v následujících zdrojích informací:

  • Microsoft.AspNetCore.Builder.ComponentsWebAssemblyApplicationBuilderExtensions.UseBlazorFrameworkFiles (odkazový zdroj)
  • Microsoft.AspNetCore.Builder.StaticFilesEndpointRouteBuilderExtensions.MapFallbackToFile (odkazový zdroj)

  Poznámka

  dokumentace odkazuje na zdrojový odkaz na ASP.NET Core načtení main větve úložiště, která představuje aktuální vývoj jednotky produktu pro další verzi ASP.NET Core. Pokud chcete vybrat větev pro jinou verzi, vyberte ji pomocí rozevíracího seznamu větve přepínače nebo značky . vyberte například release/5.0 větev pro verzi ASP.NET Core 5,0.

• V řadiči pro předpověď počasí aplikace serveru ( Controllers/WeatherForecastController.cs ) nahraďte stávající trasu ( [Route("[controller]")] ) následujícími trasami WeatherForecastController :

  [Route("FirstApp/[controller]")]
  [Route("SecondApp/[controller]")]
  

  Middleware přidané do metody serverové aplikace Startup.Configure dříve mění příchozí požadavky na /WeatherForecast buď /FirstApp/WeatherForecast nebo /SecondApp/WeatherForecast v závislosti na portu (5001/5002) nebo doméně ( firstapp.com / secondapp.com ). Aby bylo možné vracet údaje o počasí z aplikace serveru do klientských aplikací, je nutné, aby byly předchozí trasy řadiče.

Statické prostředky a knihovny tříd pro více Blazor WebAssembly aplikací

K odkazování statických prostředků použijte následující přístupy:

• Pokud je prostředek ve složce klientské aplikace wwwroot , zadejte cestu normálně:

  <img alt="..." src="/{PATH AND FILE NAME}" />
  

  {PATH AND FILE NAME}Zástupný symbol je cesta a název souboru v části wwwroot .

• Pokud je Asset ve wwwroot složce Razor knihovny tříd (RCL), odkazujte na statický prostředek v klientské aplikaci podle pokynů v Opakovaně použitelné Razor uživatelské rozhraní v knihovnách tříd pomocí ASP.NET Core :

  <img alt="..." src="_content/{PACKAGE ID}/{PATH AND FILE NAME}" />
  

  {PACKAGE ID}Zástupný symbol je ID balíčkuknihovny. V případě, že <PackageId> v souboru projektu není zadán název balíčku, je výchozím názvem sestavení projektu. {PATH AND FILE NAME}Zástupný symbol je cesta a název souboru v rámci wwwroot .

Další informace o RCLs najdete v tématech:

• využívání Razor komponent ASP.NET Core z Razor knihoven tříd
• Opakovaně použitelné Razor uživatelské rozhraní v knihovnách tříd pomocí ASP.NET Core

Samostatné nasazení

Samostatné nasazení obsluhuje Blazor WebAssembly aplikaci jako sadu statických souborů, které jsou požadovány přímo klienty. Každý statický souborový server může Blazor aplikaci zpracovat.

Samostatné prostředky nasazení jsou publikovány do /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot složky.

Azure App Service

Blazor WebAssemblyaplikace se dají nasadit do Azure App Services v Windows, která hostuje aplikaci ve službě IIS.

Nasazení samostatné Blazor WebAssembly aplikace do Azure App Service pro Linux není aktuálně podporováno. Image serveru pro Linux, která je hostitelem aplikace, není v tuto chvíli k dispozici. Pro povolení tohoto scénáře probíhá práce.

Statická webová aplikace Azure

Další informace najdete v tématu kurz: sestavení statické webové aplikace Blazor ve službě Azure static Web Apps.

IIS

Služba IIS je schopným statickým souborovým serverem pro Blazor aplikace. Chcete-li nakonfigurovat službu IIS na hostování Blazor , přečtěte si téma vytvoření statického webu ve službě IIS.

Publikované assety se vytvoří ve /bin/Release/{TARGET FRAMEWORK}/publish složce. Hostovat obsah publish složky na webovém serveru nebo v hostitelské službě.

web.config

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

• typy MIME
• Pro následující typy MIME je povolena komprese protokolu HTTP:
  • application/octet-stream
  • application/wasm
• Pravidla pro přepis adres URL jsou navázána:
  • Slouží jako podadresáře, kde se nachází statické prostředky aplikace ( wwwroot/{PATH REQUESTED} ).
  • Vytvořte záložní záložní postup, aby se požadavky na nesouborové prostředky přesměrovaly do výchozího dokumentu aplikace ve složce static assets ( wwwroot/index.html ).

Použití vlastního web.config

Chcete-li použít vlastní web.config soubor, umístěte vlastní web.config soubor do kořenové složky projektu. Konfigurace projektu pro publikování prostředků specifických pro službu IIS pomocí PublishIISAssets v souboru projektu aplikace a publikování projektu:

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

Instalace modulu URL pro přepis

Pro přepis adres URL je vyžadován modul URL Rewrite . Modul není nainstalován ve výchozím nastavení a není k dispozici pro instalaci jako funkci služby role Webový server (IIS). Modul se musí stáhnout z webu IIS. K instalaci modulu použijte instalační program webové platformy:

1. Místně přejděte na stránku ke stažení modulu pro přepsání adresy URL. V případě anglické verze vyberte WebPI a Stáhněte si instalační program WebPI. Pro jiné jazyky 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 nainstalovat a přijměte licenční podmínky. Po dokončení instalace není restartování serveru vyžadováno.

Konfigurace webu

Nastavte fyzickou cestu webu na složku aplikace. Složka obsahuje:

• web.configSoubor, 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 prostředků 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 tak, že do <handlers> <system.webServer> části souboru přidáte oddíl:

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

• Zakažte dědění kořenového oddílu (nadřazené) aplikace <system.webServer> pomocí <location> elementu s inheritInChildApplications nastavením 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ědění kořenového oddílu (nadřazené) aplikace <system.webServer> je výchozí konfigurací 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 index.html souboru aplikace na alias služby IIS, který se používá při konfiguraci dílčí aplikace v IIS.

Komprese Brotli a gzip

tato část se vztahuje jenom na samostatné Blazor WebAssembly aplikace. hostované Blazor aplikace používají výchozí soubor ASP.NET Core aplikace web.config , ne soubor propojený v této části.

Službu IIS je možné nakonfigurovat prostřednictvím web.config pro poskytování komprimovaných prostředků Brotli nebo gzip Blazor pro samostatné Blazor WebAssembly aplikace. Příklad konfiguračního souboru naleznete v tématu web.config .

Další konfigurace ukázkového web.config souboru se může vyžadovat v následujících scénářích:

• Specifikace aplikace pro jednu z následujících volání:
  • Obsluha komprimovaných souborů, které nejsou konfigurovány 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í nastavení služby IIS na úrovni serveru. V závislosti na konfiguraci na úrovni serveru může aplikace vyžadovat odlišnou konfiguraci služby IIS, než jakou web.config obsahuje ukázkový soubor.

Řešení potíží

Pokud dojde k chybě 500 – interní chyba serveru a správce služby IIS vyvolá chyby při pokusu o přístup ke konfiguraci webu, potvrďte, že je nainstalován modul URL pro přepis. Pokud modul není nainstalován, web.config soubor nelze analyzovat službou IIS. Tím se zabrání tomu, aby správce služby IIS načetl konfiguraci webu a web ze Blazor statických souborů obsluhy.

Další informace o řešení potíží s nasazeními služby IIS najdete v tématu Řešení ASP.NET Core potíží s Azure App Service a službou IIS .

Azure Storage

hostování statického souboru Azure Storage umožňuje Blazor hostování aplikací bez serveru. podporují se názvy vlastních domén, Content Delivery Network Azure (CDN) a HTTPS.

Když je u služby BLOB Service povolené hostování statických webů v účtu úložiště:

• Nastavte název dokumentu indexu na index.html .
• Nastavte cestu k chybovému dokumentu na index.html . Razor součásti a jiné koncové body, které nejsou v souboru, se neukládají na fyzických cestách ve statickém obsahu uloženém službou BLOB Service. Když se přijme žádost o jeden z těchto prostředků, kterou Blazor by měl směrovač zpracovat, chyba 404 – nenalezená služba BLOB Service směruje požadavek na cestu k chybovému dokumentu. index.htmlVrátí se objekt BLOB a Blazor směrovač načte a zpracuje cestu.

Pokud nejsou za běhu načteny soubory z důvodu nevhodných typů MIME v Content-Type hlavičkách souborů, 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).

• Změňte typy MIME ( Content-Type hlavičky) souborů po nasazení aplikace.

  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 klikněte na tlačítko Uložit .

Další informace najdete v tématu statické hostování webů v Azure Storage.

Nginx

Následující nginx.conf soubor je zjednodušený a ukazuje, jak nakonfigurovat Nginx pro odeslání index.html souboru pokaždé, když 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 přenosové rychlosti Nginx pomocí můžou limit_req Blazor WebAssembly aplikace vyžadovat velkou burst hodnotu parametru, aby odpovídala poměrně velkému počtu požadavků, které aplikace vytvořila. Zpočátku nastavte hodnotu aspoň 60:

http {
    server {
        ...

        location / {
            ...

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

Zvyšte hodnotu, pokud nástroje pro vývojáře v prohlížeči nebo síťový provoz označují, že žádosti dostávají stavový kód Nedostupnosti 503-Service .

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

Apache

Nasazení Blazor WebAssembly aplikace na CentOS 7 nebo novější:

1. Vytvořte konfigurační soubor Apache. V následujícím příkladu 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
       AddType application/octet-stream .dll
   
       <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>
   

2. Soubor konfigurace Apache umístěte do /etc/httpd/conf.d/ adresáře, který je výchozím adresářem konfigurace Apache v CentOS 7.

3. Umístěte soubory aplikace do /var/www/blazorapp adresáře (umístění zadaného do DocumentRoot konfiguračního souboru).

4. Restartujte službu Apache.

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

Stránky GitHubu

Chcete-li zpracovat přepisy 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 tématu úložiště SteveSandersonMS/ Blazor OnGitHubPages GitHub:

• wwwroot/404.html
• Živý web)

Při použití webu projektu namísto webu organizace aktualizujte <base> značku v wwwroot/index.html . nastavte href hodnotu atributu na GitHub název úložiště s koncovým lomítkem (například /my-repository/ ). v úložišti SteveSandersonMS/ Blazor OnGitHubPages GitHubse základ href aktualizuje při publikování pomocí .github/workflows/main.yml konfiguračního souboru.

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

--contentrootArgument nastavuje absolutní cestu k adresáři, který obsahuje soubory obsahu aplikace (kořen obsahu). V následujících příkladech /content-root-path je kořenová cesta obsahu aplikace.

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

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

• přidejte položku do launchSettings.json souboru aplikace v profilu IIS Express . toto nastavení se používá při spuštění aplikace s ladicím programem Visual Studio a z příkazového řádku s dotnet run .

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

• v Visual Studio zadejte argument v části vlastnosti > ladit > argumenty aplikace. nastavení argumentu na stránce vlastností Visual Studio přidá do launchSettings.json souboru argument.

  --contentroot=/content-root-path
  

Základ cesty

--pathbaseArgument nastaví základní cestu aplikace pro aplikaci spouštěnou místně s nekořenovou cestou relativní adresy URL ( <base> značka href je nastavená na jinou cestu než / pro pracovní a produkční). V následujících příkladech /relative-URL-path je základ cesty aplikace. Další informace najdete v tématu základní cesta k aplikaci.

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

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

• přidejte položku do launchSettings.json souboru aplikace v profilu IIS Express . toto nastavení se používá při spuštění aplikace s ladicím programem Visual Studio a z příkazového řádku s dotnet run .

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

• v Visual Studio zadejte argument v části vlastnosti > ladit > argumenty aplikace. nastavení argumentu na stránce vlastností Visual Studio přidá do launchSettings.json souboru argument.

  --pathbase=/relative-URL-path
  

Adresy URL

--urlsArgument nastaví IP adresy nebo adresy hostitelů s porty a protokoly, které se mají na požadavky naslouchat.

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

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

• přidejte položku do launchSettings.json souboru aplikace v profilu IIS Express . toto nastavení se používá při spuštění aplikace s ladicím programem Visual Studio a z příkazového řádku s dotnet run .

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

• v Visual Studio zadejte argument v části vlastnosti > ladit > argumenty aplikace. nastavení argumentu na stránce vlastností Visual Studio přidá do launchSettings.json souboru argument.

  --urls=http://127.0.0.1:0
  

Konfigurace ořezávání

Blazor provede oříznutí mezilehlého jazyka (IL) pro každé sestavení vydané verze, aby se odebralo zbytečné IL z výstupních sestavení. Další informace naleznete v tématu Konfigurace oříznutého ASP.NET Core Blazor.

Změna přípony filename souborů DLL

V případě, že potřebujete změnit příponu filename pro publikované .dll soubory aplikace, postupujte podle pokynů v této části.

po publikování aplikace použijte skript prostředí nebo DevOps kanál sestavení pro přejmenování .dll souborů tak, aby používaly jinou příponu souboru. Zaměřte se na .dll soubory v wwwroot adresáři publikovaného výstupu aplikace (například {CONTENT ROOT}/bin/Release/netstandard2.1/publish/wwwroot ).

V následujících příkladech .dll jsou soubory přejmenovány, aby používaly .bin příponu souboru.

Ve Windows:

dir .\_framework\_bin | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content .\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content .\_framework\blazor.boot.json

Pokud se také používají prostředky pracovního procesu služby, přidejte následující příkaz:

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

V systému Linux nebo macOS:

for f in _framework/_bin/*; do mv "$f" "`echo $f | sed -e 's/\.dll/.bin/g'`"; done
sed -i 's/\.dll"/.bin"/g' _framework/blazor.boot.json

Pokud se také používají prostředky pracovního procesu služby, přidejte následující příkaz:

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

Chcete-li použít jinou příponu souboru než .bin , nahraďte .bin v předchozích příkazech.

Pro vyřešení komprimovaných blazor.boot.json.gz blazor.boot.json.br souborů proveďte jednu z následujících přístupů:

• Odeberte komprimované blazor.boot.json.gz soubory a blazor.boot.json.br . Komprese je u tohoto přístupu zakázána.
• Opětovná komprimace aktualizovaného blazor.boot.json souboru.

Předchozí pokyny platí i v případě, že se aktivují prostředky pracovního procesu. Odeberte nebo znovu proveďte komprimaci wwwroot/service-worker-assets.js.br a wwwroot/service-worker-assets.js.gz . V opačném případě kontroly integrity souborů selžou v prohlížeči.

následující příklad Windows používá skript prostředí PowerShell umístěný v kořenovém adresáři projektu.

ChangeDLLExtensions.ps1::

param([string]$filepath,[string]$tfm)
dir $filepath\bin\Release\$tfm\wwwroot\_framework\_bin | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content $filepath\bin\Release\$tfm\wwwroot\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\wwwroot\_framework\blazor.boot.json
Remove-Item $filepath\bin\Release\$tfm\wwwroot\_framework\blazor.boot.json.gz

Pokud se také používají prostředky pracovního procesu služby, přidejte následující příkaz:

((Get-Content $filepath\bin\Release\$tfm\wwwroot\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\wwwroot\service-worker-assets.js

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

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

Vyřešit selhání kontroly integrity

Při Blazor WebAssembly stažení spouštěcích souborů aplikace instruuje prohlížeč, aby prováděl kontroly integrity na odpovědích. Používá informace v blazor.boot.json souboru k určení očekávaných hodnot hash SHA-256 pro .dll , .wasm a dalších souborů. To je užitečné z následujících důvodů:

• Zajišťuje neriziku načtení nekonzistentní sady souborů, například pokud se na váš webový server použije nové nasazení, zatímco uživatel právě stahuje soubory aplikace. Nekonzistentní soubory mohou vést k nedefinovanému chování.
• To zajišťuje, že prohlížeč uživatele nikdy neukládá do mezipaměti nekonzistentní ani neplatné odpovědi, což by mohlo zabránit spuštění aplikace i v případě, že stránku ručně aktualizují.
• Umožňuje bezpečné ukládání odpovědí do mezipaměti a dokonce i kontrolu nad změnami na straně serveru, dokud se nezmění očekávaná hodnota hash SHA-256, takže následné načtení stránky zahrnuje méně požadavků a dokončí mnohem rychleji.

Pokud váš 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 v prohlížeči chybová zpráva podobná následující:

Nepovedlo se najít platný výtah v atributu integrity pro prostředek https://myapp.example.com/\_framework/My BlazorApp.dll s vypočtenou integritou SHA-256 IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY =. Prostředek je zablokovaný.

Ve většině případů to není problém s kontrolou integrity samotnou. Místo toho znamená, že došlo k nějakému problému a kontrola integrity vás upozorní na tento jiný problém.

Diagnostikování problémů s integritou

Při sestavení aplikace vygenerovaný blazor.boot.json manifest popisuje hodnoty hash SHA-256 svých spouštěcích prostředků (například,, .dll .wasm a dalších souborů) v době, kdy je vytvořen výstup sestavení. Kontrola integrity projde, dokud hodnoty hash SHA-256 ve blazor.boot.json shodě se soubory doručenými do prohlížeče.

Běžné důvody, proč se tato chyba nezdařila:

• Odpověď webového serveru je chyba (například Chyba 404-nenalezena nebo 500-interní chyba serveru) místo souboru, který prohlížeč požadoval. Prohlížeč tuto zprávu oznamuje jako selhání kontroly integrity a ne jako odpověď.
• Něco změnilo obsah souborů mezi sestavením a doručením souborů do prohlížeče. K tomu může dojít:
  • Pokud vytváříte nebo vytváříte nástroje, můžete výstup sestavení ručně změnit.
  • Pokud nějaký aspekt procesu nasazení změnil soubory. například pokud používáte mechanizmus pro nasazení na základě gitu, pamatujte, že Git transparentně převede konce řádků Windows stylu na konce řádků ve stylu Unix, pokud potvrdíte soubory v Windows a vrátíte se na Linux. Změna konců řádků souboru mění hodnoty hash SHA-256. Chcete-li se tomuto problému vyhnout, zvažte použití .gitattributes pro považovat artefakty sestavení jako binary soubory.
  • Webový server upraví obsah souboru v rámci obsluhy. Například některé sítě pro distribuci obsahu (sítě CDN) se automaticky pokusí minimalizuje HTML, takže se upraví. Tyto funkce možná budete muset zakázat.

Postup diagnostiky, které z těchto případů platí:

1. Všimněte si, že soubor spouští chybu načtením chybové zprávy.
2. Otevřete vývojářské nástroje v prohlížeči 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í. Vyhledejte soubor, který aktivuje chybu v tomto seznamu.
3. V odpovědi ověřte stavový kód protokolu HTTP. Pokud server vrátí jinou hodnotu než 200-OK (nebo jiný stavový kód 2xx), budete mít problém s diagnostikou na straně serveru. Například stavový kód 403 znamená problém s autorizací, zatímco stavový kód 500 znamená, že se server nedaří nespecifikovaným způsobem. Diagnostikujte a opravte aplikaci v protokolech na straně serveru.
4. Pokud je stavový kód 200 – OK pro prostředek, podívejte se na obsah odpovědi v vývojářských nástrojích prohlížeče a zkontrolujte, jestli se obsah shoduje s očekávanými daty. Běžným problémem je například nesprávně nakonfigurovaná směrování, takže požadavky vrátí 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. V takovém případě máte k diagnostice problém s směrováním na straně serveru.
5. V tématu řešení potíží s integritou skriptu PowerShelluse můžete pokusit ověřit publikovaný a nasazený výstup aplikace.

Pokud potvrdíte, že server vrací plausibly správná data, musí být něco jiného, než je třeba upravit obsah mezi sestavením a doručením souboru. Postup pro prošetření:

• Projděte si mechanismus sestavení sada nástrojů and Deployment v případě, že upravujete soubory po sestavení souborů. Příkladem je, že Git transformuje konce řádků souboru, jak je popsáno výše.
• v případě, že jsou nastavené tak, aby dynamicky měnily odpovědi (například pokus o minimalizuje HTML), prověřte webový server nebo konfiguraci CDN. Pro webový server je to pro implementaci komprese HTTP nutné content-encoding: br content-encoding: gzip , protože to neovlivní výsledek po dekompresi. U webového serveru ale není dobré upravovat nekomprimovaná data.

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

integrity.ps1K ověření publikované a nasazené aplikace použijte skript prostředí PowerShell Blazor . Skript se poskytuje pro PowerShell Core 6 jako výchozí bod, když má aplikace problémy s integritou, které Blazor Architektura nedokáže identifikovat. Pro vaše aplikace se může vyžadovat přizpůsobení skriptu, včetně toho, jestli běží na verzi PowerShellu novější než 6.2.7 verze.

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

• Změnili jste soubor v publikovaném výstupu, aniž byste ho museli realizovat.
• Aplikace nebyla správně nasazena do cíle nasazení nebo došlo ke změně v rámci prostředí cíle nasazení.
• Existují rozdíly mezi nasazenou aplikací a výstupem z publikování aplikace.

V příkazovém prostředí PowerShell volejte skript s následujícím příkazem:

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

Zástupné symboly

• {BASE URL}: Adresa URL nasazené aplikace.
• {PUBLISH OUTPUT FOLDER}: Cesta ke publish složce aplikace nebo umístění, 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ázat kontrolu integrity pro aplikace, které nejsou PWA

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

Můžou nastat případy, kdy se webový server nemůže spoléhat na to, že vrátí konzistentní odpovědi, a nemáte žádnou volbu, ale zakážete kontroly integrity. Chcete-li zakázat kontroly integrity, přidejte následující do skupiny vlastností v Blazor WebAssembly .csproj souboru projektu:

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResources také zakáže Blazor výchozí chování ukládání do mezipaměti .dll , .wasm a dalších souborů na základě jejich hash SHA-256, protože tato vlastnost označuje, že se na správnost nedají spoléhat hodnoty hash SHA-256. I s tímto nastavením může normální mezipaměť protokolu HTTP v prohlížeči pořád tyto soubory ukládat do mezipaměti, ale bez ohledu na to, jestli se k tomu dojde, závisí na konfiguraci webového serveru a na cache-control hlavičkách, které obsluhuje.

Zakázat kontrolu integrity pro PWAs

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ů aplikace pro použití v režimu offline. Jedná se o samostatný proces z normálního spouštěcího mechanismu aplikace a má svou vlastní samostatnou logiku kontroly integrity.

Uvnitř service-worker.published.js 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));

Opět se zakazováním kontroly integrity znamená, že ztratíte bezpečnostní záruky, které nabízí kontrola integrity. Například existuje riziko, že pokud je v prohlížeči uživatele mezipaměť aplikace do mezipaměti přesně v okamžiku, kdy nasazujete novou verzi, mohli byste ukládat do mezipaměti některé soubory ze starého nasazení a některé z nového nasazení. Pokud k tomu dojde, aplikace se zablokuje v nefunkčním stavu, dokud nenainstalujete další aktualizaci.

S Blazor WebAssembly modelem hostování:

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

Podporují se tyto strategie nasazení:

• Blazoraplikaci obsluhuje aplikace ASP.NET Core. tato strategie je popsaná v části hostované nasazení s ASP.NET Core .
• BlazorAplikace se umístí na statický hostující webový server nebo službu, kde rozhraní .NET se k obsluze aplikace nepoužívá Blazor . Tato strategie je popsaná v části samostatné nasazení , která obsahuje informace o hostování Blazor WebAssembly aplikace jako dílčí aplikace služby IIS.

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

Přizpůsobte způsob načítání spouštěcích prostředků pomocí loadBootResource rozhraní API. Další informace naleznete v tématu ASP.NET Core Blazor Úvod.

Komprese

Při Blazor WebAssembly publikování aplikace je výstup během publikování staticky komprimován, aby se snížila velikost aplikace a odstranila se režie pro kompresi za běhu. Používají se následující kompresní algoritmy:

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

Blazor spoléhá na hostitele, který obsluhuje příslušné komprimované soubory. při použití hostovaného projektu ASP.NET Core je hostitelský projekt schopný provádět vyjednávání obsahu a obsluhovat staticky komprimované soubory. Při hostování Blazor WebAssembly samostatné aplikace může být nutné provést další práci, aby bylo zajištěno, že budou obsluhovány staticky komprimované soubory:

• web.configKonfiguraci komprese služby IIS najdete v části IIS: Brotli a komprese GZip .

• při hostování řešení statického hostování, které nepodporují vyjednávání se staticky komprimovaným souborem, jako je například GitHub stránky, zvažte konfiguraci aplikace pro načtení a dekódování Brotli komprimovaných souborů:

  • získejte dekodér JavaScript Brotli z úložiště google/Brotli GitHub. Soubor dekodéru minifikovaného se pojmenuje decode.min.js a nachází se ve js složceúložiště.

    Poznámka

    Pokud se minifikovaného verze decode.js skriptu ( decode.min.js ) nezdařila, zkuste místo toho použít unminified verze ( decode.js ).

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

    V wwwroot/index.html souboru nastavte autostart false Blazor příznak on <script> :

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

    Po Blazor <script> značce a před uzavírací </body> značkou přidejte následující blok kódu JavaScriptu <script> :

    <script type="module">
      import { BrotliDecode } from './decode.min.js';
      Blazor.start({
        loadBootResource: function (type, name, defaultUri, integrity) {
          if (type !== 'dotnetjs' && location.hostname !== 'localhost') {
            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ů naleznete v tématu ASP.NET Core Blazor Úvod .

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

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

BlazorEnableCompressionVlastnost může být předána dotnet publish příkazu s následující syntaxí v příkazovém prostředí:

dotnet publish -p:BlazorEnableCompression=false

Přepište adresy URL pro správné směrování.

Požadavky směrování na součásti stránky v Blazor WebAssembly aplikaci nejsou stejně jednoduché jako požadavky směrování v Blazor Server hostované aplikaci. Vezměte v úvahu Blazor WebAssembly aplikaci se dvěma součástmi:

• Main.razor: Načte do kořenového adresáře aplikace a obsahuje odkaz na About komponentu ( href="About" ).
• About.razor: About součást.

Pokud je výchozí dokument aplikace požadován pomocí panelu Adresa prohlížeče (například https://www.contoso.com/ ):

1. Prohlížeč vytvoří požadavek.
2. Vrátí se výchozí stránka, což je obvykle index.html .
3. index.html napředá aplikaci.
4. Blazorse načte směrovač a Razor Main Komponenta se vykreslí.

Na hlavní stránce vyberte odkaz na About komponentu na klientovi, protože Blazor směrovač zastaví v prohlížeči, aby odeslal požadavek na Internet www.contoso.com pro About a sloužil přímo vykreslené About součásti. Všechny požadavky na vnitřní koncové body v Blazor WebAssembly aplikaci fungují stejným způsobem: požadavky neaktivují požadavky založené na prohlížeči na prostředky hostované na serveru na internetu. Směrovač zpracovává požadavky interně.

Pokud je žádost vytvořena pomocí panelu Adresa prohlížeče pro www.contoso.com/About , požadavek se nezdařil. Žádný takový prostředek na internetovém hostiteli aplikace neexistuje, takže se vrátí odpověď 404 – Nenalezeno .

Vzhledem k tomu, že prohlížeče připravují žádosti na internetové hostitele pro stránky na straně klienta, webové servery a hostitelské služby musí přepsat všechny požadavky na prostředky, které nejsou na stránce fyzicky na serveru index.html . Když index.html se vrátí, Blazor směrovač aplikace 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 .

Hostované nasazení s ASP.NET Core

hostované nasazení obsluhuje Blazor WebAssembly aplikaci prohlížeči z ASP.NET Core aplikace , která běží na webovém serveru.

Klientská Blazor WebAssembly aplikace se publikuje do /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot složky serverové aplikace spolu s dalšími statickými webovými prostředky serverové aplikace. Obě aplikace se nasazují dohromady. vyžaduje se webový server, který podporuje hostování aplikace ASP.NET Core. v případě hostovaného nasazení Visual Studio zahrnuje šablonu projektu Blazor WebAssembly aplikace ( blazorwasm šablona při použití dotnet new příkazu) s Hosted vybranou možností ( -ho|--hosted při použití dotnet new příkazu).

Další informace najdete v následujících článcích:

• ASP.NET Core hostování a nasazení aplikací:Hostování a nasazení ASP.NET Core
• Nasazení do Azure App Service: Publikování ASP.NET Core aplikace do Azure pomocí Visual Studio
• Blazor šablony projektu: ASP.NET Core Blazor struktura projektu

Hostované nasazení s více Blazor WebAssembly aplikacemi

Konfigurace aplikací

Hostovaná Blazor řešení můžou sloužit více Blazor WebAssembly aplikacím.

V následujícím příkladu:

• Úvodní (první) klientská aplikace je výchozí projekt klienta řešení vytvořený ze Blazor WebAssembly šablony projektu. První klientská aplikace je přístupná v prohlížeči z adresy URL /FirstApp na portu 5001 nebo s hostitelem firstapp.com .
• Do řešení se přidá druhá klientská aplikace SecondBlazorApp.Client . Druhá klientská aplikace je přístupná v prohlížeči z adresy URL /SecondApp na portu 5002 nebo s hostitelem secondapp.com .

Použijte existující hostované Blazor řešení nebo vytvořte nové řešení ze Blazor šablony hostovaného projektu:

• V souboru projektu klientské aplikace přidejte <StaticWebAssetBasePath> vlastnost do pole <PropertyGroup> s hodnotou, FirstApp abyste nastavili základní cestu pro statické prostředky projektu:

  <PropertyGroup>
    ...
    <StaticWebAssetBasePath>FirstApp</StaticWebAssetBasePath>
  </PropertyGroup>
  

• Přidání druhé klientské aplikace do řešení:

  • Přidejte do složky řešení složku s názvem SecondClient . Složka řešení vytvořená v šabloně projektu obsahuje následující soubor řešení a složky po SecondClient Přidání složky:

    • Client složky
    • SecondClient složky
    • Server složky
    • Shared složky
    • {SOLUTION NAME}.sln souborů

    Zástupný symbol {SOLUTION NAME} je název řešení.

  • Vytvořte Blazor WebAssembly aplikaci s názvem SecondBlazorApp.Client ve SecondClient složce ze Blazor WebAssembly šablony projektu.

  • V SecondBlazorApp.Client souboru projektu aplikace:

    • Přidejte <StaticWebAssetBasePath> vlastnost do pole <PropertyGroup> s hodnotou SecondApp :

      <PropertyGroup>
        ...
        <StaticWebAssetBasePath>SecondApp</StaticWebAssetBasePath>
      </PropertyGroup>
      

    • Přidat odkaz na projekt do Shared projektu:

      <ItemGroup>
        <ProjectReference Include="..\Shared\{SOLUTION NAME}.Shared.csproj" />
      </ItemGroup>
      

      Zástupný symbol {SOLUTION NAME} je název řešení.

• V souboru projektu aplikace serveru vytvořte odkaz na projekt pro přidanou SecondBlazorApp.Client klientskou aplikaci:

  <ItemGroup>
    <ProjectReference Include="..\Client\{SOLUTION NAME}.Client.csproj" />
    <ProjectReference Include="..\SecondClient\SecondBlazorApp.Client.csproj" />
    <ProjectReference Include="..\Shared\{SOLUTION NAME}.Shared.csproj" />
  </ItemGroup>
  

  Zástupný symbol {SOLUTION NAME} je název řešení.

• V souboru serverové aplikace Properties/launchSettings.json Nakonfigurujte applicationUrl Kestrel profil ( {SOLUTION NAME}.Server ) pro přístup k klientským aplikacím na portech 5001 a 5002:

  "applicationUrl": "https://localhost:5001;https://localhost:5002",
  

• V metodě serverové aplikace Startup.Configure ( Startup.cs ) odeberte následující řádky, které se zobrazí po volání UseHttpsRedirection :

  -app.UseBlazorFrameworkFiles();
  -app.UseStaticFiles();
  
  -app.UseRouting();
  
  -app.UseEndpoints(endpoints =>
  -{
  -    endpoints.MapRazorPages();
  -    endpoints.MapControllers();
  -    endpoints.MapFallbackToFile("index.html");
  -});
  

  Přidejte middleware, který mapuje požadavky na klientské aplikace. Následující příklad konfiguruje middleware ke spuštění v následujících případech:

  • Port žádosti je buď 5001 pro původní klientskou aplikaci, nebo 5002 pro přidanou klientskou aplikaci.

  • Hostitel žádosti je buď firstapp.com pro původní klientskou aplikaci, nebo secondapp.com pro přidanou klientskou aplikaci.

    Poznámka

    Příklad uvedený v této části vyžaduje další konfiguraci pro:

    • Přístup k aplikacím v ukázkových doménách hostitelů firstapp.com a secondapp.com .
    • Certifikáty pro klientské aplikace, které umožňují zabezpečení TLS (HTTPS).

    Požadovaná konfigurace překračuje rozsah tohoto článku a závisí na tom, jak je řešení hostované. Další informace najdete v článcích o hostiteli a nasazení.

  Vložte následující kód, kde byly řádky odebrány dříve:

  app.MapWhen(ctx => ctx.Request.Host.Port == 5001 || 
      ctx.Request.Host.Equals("firstapp.com"), first =>
  {
      first.Use((ctx, nxt) =>
      {
          ctx.Request.Path = "/FirstApp" + ctx.Request.Path;
          return nxt();
      });
  
      first.UseBlazorFrameworkFiles("/FirstApp");
      first.UseStaticFiles();
      first.UseStaticFiles("/FirstApp");
      first.UseRouting();
  
      first.UseEndpoints(endpoints =>
      {
          endpoints.MapControllers();
          endpoints.MapFallbackToFile("/FirstApp/{*path:nonfile}", 
              "FirstApp/index.html");
      });
  });
  
  app.MapWhen(ctx => ctx.Request.Host.Port == 5002 || 
      ctx.Request.Host.Equals("secondapp.com"), second =>
  {
      second.Use((ctx, nxt) =>
      {
          ctx.Request.Path = "/SecondApp" + ctx.Request.Path;
          return nxt();
      });
  
      second.UseBlazorFrameworkFiles("/SecondApp");
      second.UseStaticFiles();
      second.UseStaticFiles("/SecondApp");
      second.UseRouting();
  
      second.UseEndpoints(endpoints =>
      {
          endpoints.MapControllers();
          endpoints.MapFallbackToFile("/SecondApp/{*path:nonfile}", 
              "SecondApp/index.html");
      });
  });
  

  Další informace o UseStaticFiles naleznete v tématu BlazorASP.NET Core statické soubory .

  Další informace o UseBlazorFrameworkFiles a MapFallbackToFile najdete v následujících zdrojích informací:

  • Microsoft.AspNetCore.Builder.ComponentsWebAssemblyApplicationBuilderExtensions.UseBlazorFrameworkFiles (odkazový zdroj)
  • Microsoft.AspNetCore.Builder.StaticFilesEndpointRouteBuilderExtensions.MapFallbackToFile (odkazový zdroj)

  Poznámka

  dokumentace odkazuje na zdrojový odkaz na ASP.NET Core načtení main větve úložiště, která představuje aktuální vývoj jednotky produktu pro další verzi ASP.NET Core. Pokud chcete vybrat větev pro jinou verzi, vyberte ji pomocí rozevíracího seznamu větve přepínače nebo značky . vyberte například release/5.0 větev pro verzi ASP.NET Core 5,0.

• V řadiči pro předpověď počasí aplikace serveru ( Controllers/WeatherForecastController.cs ) nahraďte stávající trasu ( [Route("[controller]")] ) následujícími trasami WeatherForecastController :

  [Route("FirstApp/[controller]")]
  [Route("SecondApp/[controller]")]
  

  Middleware přidané do metody serverové aplikace Startup.Configure dříve mění příchozí požadavky na /WeatherForecast buď /FirstApp/WeatherForecast nebo /SecondApp/WeatherForecast v závislosti na portu (5001/5002) nebo doméně ( firstapp.com / secondapp.com ). Aby bylo možné vracet údaje o počasí z aplikace serveru do klientských aplikací, je nutné, aby byly předchozí trasy řadiče.

Statické prostředky a knihovny tříd pro více Blazor WebAssembly aplikací

K odkazování statických prostředků použijte následující přístupy:

• Pokud je prostředek ve složce klientské aplikace wwwroot , zadejte cestu normálně:

  <img alt="..." src="/{PATH AND FILE NAME}" />
  

  {PATH AND FILE NAME}Zástupný symbol je cesta a název souboru v části wwwroot .

• Pokud je Asset ve wwwroot složce Razor knihovny tříd (RCL), odkazujte na statický prostředek v klientské aplikaci podle pokynů v Opakovaně použitelné Razor uživatelské rozhraní v knihovnách tříd pomocí ASP.NET Core :

  <img alt="..." src="_content/{PACKAGE ID}/{PATH AND FILE NAME}" />
  

  {PACKAGE ID}Zástupný symbol je ID balíčkuknihovny. V případě, že <PackageId> v souboru projektu není zadán název balíčku, je výchozím názvem sestavení projektu. {PATH AND FILE NAME}Zástupný symbol je cesta a název souboru v rámci wwwroot .

Další informace o RCLs najdete v tématech:

• využívání Razor komponent ASP.NET Core z Razor knihoven tříd
• Opakovaně použitelné Razor uživatelské rozhraní v knihovnách tříd pomocí ASP.NET Core

Samostatné nasazení

Samostatné nasazení obsluhuje Blazor WebAssembly aplikaci jako sadu statických souborů, které jsou požadovány přímo klienty. Každý statický souborový server může Blazor aplikaci zpracovat.

Samostatné prostředky nasazení jsou publikovány do /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot složky.

Azure App Service

Blazor WebAssemblyaplikace se dají nasadit do Azure App Services v Windows, která hostuje aplikaci ve službě IIS.

Nasazení samostatné Blazor WebAssembly aplikace do Azure App Service pro Linux není aktuálně podporováno. Image serveru pro Linux, která je hostitelem aplikace, není v tuto chvíli k dispozici. Pro povolení tohoto scénáře probíhá práce.

Statická webová aplikace Azure

Další informace najdete v tématu kurz: sestavení statické webové aplikace Blazor ve službě Azure static Web Apps.

IIS

Služba IIS je schopným statickým souborovým serverem pro Blazor aplikace. Chcete-li nakonfigurovat službu IIS na hostování Blazor , přečtěte si téma vytvoření statického webu ve službě IIS.

Publikované assety se vytvoří ve /bin/Release/{TARGET FRAMEWORK}/publish složce. Hostovat obsah publish složky na webovém serveru nebo v hostitelské službě.

web.config

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

• typy MIME
• Pro následující typy MIME je povolena komprese protokolu HTTP:
  • application/octet-stream
  • application/wasm
• Pravidla pro přepis adres URL jsou navázána:
  • Slouží jako podadresáře, kde se nachází statické prostředky aplikace ( wwwroot/{PATH REQUESTED} ).
  • Vytvořte záložní záložní postup, aby se požadavky na nesouborové prostředky přesměrovaly do výchozího dokumentu aplikace ve složce static assets ( wwwroot/index.html ).

Použití vlastního web.config

Chcete-li použít vlastní web.config soubor, umístěte vlastní web.config soubor do kořenové složky projektu. Konfigurace projektu pro publikování prostředků specifických pro službu IIS pomocí PublishIISAssets v souboru projektu aplikace a publikování projektu:

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

Instalace modulu URL pro přepis

Pro přepis adres URL je vyžadován modul URL Rewrite . Modul není nainstalován ve výchozím nastavení a není k dispozici pro instalaci jako funkci služby role Webový server (IIS). Modul se musí stáhnout z webu IIS. K instalaci modulu použijte instalační program webové platformy:

1. Místně přejděte na stránku ke stažení modulu pro přepsání adresy URL. V případě anglické verze vyberte WebPI a Stáhněte si instalační program WebPI. Pro jiné jazyky 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 nainstalovat a přijměte licenční podmínky. Po dokončení instalace není restartování serveru vyžadováno.

Konfigurace webu

Nastavte fyzickou cestu webu na složku aplikace. Složka obsahuje:

• web.configSoubor, 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 prostředků 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 tak, že do <handlers> <system.webServer> části souboru přidáte oddíl:

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

• Zakažte dědění kořenového oddílu (nadřazené) aplikace <system.webServer> pomocí <location> elementu s inheritInChildApplications nastavením 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ědění kořenového oddílu (nadřazené) aplikace <system.webServer> je výchozí konfigurací 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 index.html souboru aplikace na alias služby IIS, který se používá při konfiguraci dílčí aplikace v IIS.

Komprese Brotli a gzip

tato část se vztahuje jenom na samostatné Blazor WebAssembly aplikace. hostované Blazor aplikace používají výchozí soubor ASP.NET Core aplikace web.config , ne soubor propojený v této části.

Službu IIS je možné nakonfigurovat prostřednictvím web.config pro poskytování komprimovaných prostředků Brotli nebo gzip Blazor pro samostatné Blazor WebAssembly aplikace. Příklad konfiguračního souboru naleznete v tématu web.config .

Další konfigurace ukázkového web.config souboru se může vyžadovat v následujících scénářích:

• Specifikace aplikace pro jednu z následujících volání:
  • Obsluha komprimovaných souborů, které nejsou konfigurovány 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í nastavení služby IIS na úrovni serveru. V závislosti na konfiguraci na úrovni serveru může aplikace vyžadovat odlišnou konfiguraci služby IIS, než jakou web.config obsahuje ukázkový soubor.

Řešení potíží

Pokud dojde k chybě 500 – interní chyba serveru a správce služby IIS vyvolá chyby při pokusu o přístup ke konfiguraci webu, potvrďte, že je nainstalován modul URL pro přepis. Pokud modul není nainstalován, web.config soubor nelze analyzovat službou IIS. Tím se zabrání tomu, aby správce služby IIS načetl konfiguraci webu a web ze Blazor statických souborů obsluhy.

Další informace o řešení potíží s nasazeními služby IIS najdete v tématu Řešení ASP.NET Core potíží s Azure App Service a službou IIS .

Azure Storage

hostování statického souboru Azure Storage umožňuje Blazor hostování aplikací bez serveru. podporují se názvy vlastních domén, Content Delivery Network Azure (CDN) a HTTPS.

Když je u služby BLOB Service povolené hostování statických webů v účtu úložiště:

• Nastavte název dokumentu indexu na index.html .
• Nastavte cestu k chybovému dokumentu na index.html . Razor součásti a jiné koncové body, které nejsou v souboru, se neukládají na fyzických cestách ve statickém obsahu uloženém službou BLOB Service. Když se přijme žádost o jeden z těchto prostředků, kterou Blazor by měl směrovač zpracovat, chyba 404 – nenalezená služba BLOB Service směruje požadavek na cestu k chybovému dokumentu. index.htmlVrátí se objekt BLOB a Blazor směrovač načte a zpracuje cestu.

Pokud nejsou za běhu načteny soubory z důvodu nevhodných typů MIME v Content-Type hlavičkách souborů, 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).

• Změňte typy MIME ( Content-Type hlavičky) souborů po nasazení aplikace.

  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 klikněte na tlačítko Uložit .

Další informace najdete v tématu statické hostování webů v Azure Storage.

Nginx

Následující nginx.conf soubor je zjednodušený a ukazuje, jak nakonfigurovat Nginx pro odeslání index.html souboru pokaždé, když 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 přenosové rychlosti Nginx pomocí můžou limit_req Blazor WebAssembly aplikace vyžadovat velkou burst hodnotu parametru, aby odpovídala poměrně velkému počtu požadavků, které aplikace vytvořila. Zpočátku nastavte hodnotu aspoň 60:

http {
    server {
        ...

        location / {
            ...

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

Zvyšte hodnotu, pokud nástroje pro vývojáře v prohlížeči nebo síťový provoz označují, že žádosti dostávají stavový kód Nedostupnosti 503-Service .

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

Apache

Nasazení Blazor WebAssembly aplikace na CentOS 7 nebo novější:

1. Vytvořte konfigurační soubor Apache. V následujícím příkladu 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
       AddType application/octet-stream .dll
   
       <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>
   

2. Soubor konfigurace Apache umístěte do /etc/httpd/conf.d/ adresáře, který je výchozím adresářem konfigurace Apache v CentOS 7.

3. Umístěte soubory aplikace do /var/www/blazorapp adresáře (umístění zadaného do DocumentRoot konfiguračního souboru).

4. Restartujte službu Apache.

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

Stránky GitHubu

Chcete-li zpracovat přepisy 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 tématu úložiště SteveSandersonMS/ Blazor OnGitHubPages GitHub:

• wwwroot/404.html
• Živý web)

Při použití webu projektu namísto webu organizace aktualizujte <base> značku v wwwroot/index.html . nastavte href hodnotu atributu na GitHub název úložiště s koncovým lomítkem (například /my-repository/ ). v úložišti SteveSandersonMS/ Blazor OnGitHubPages GitHubse základ href aktualizuje při publikování pomocí .github/workflows/main.yml konfiguračního souboru.

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

--contentrootArgument nastavuje absolutní cestu k adresáři, který obsahuje soubory obsahu aplikace (kořen obsahu). V následujících příkladech /content-root-path je kořenová cesta obsahu aplikace.

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

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

• přidejte položku do launchSettings.json souboru aplikace v profilu IIS Express . toto nastavení se používá při spuštění aplikace s ladicím programem Visual Studio a z příkazového řádku s dotnet run .

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

• v Visual Studio zadejte argument v části vlastnosti > ladit > argumenty aplikace. nastavení argumentu na stránce vlastností Visual Studio přidá do launchSettings.json souboru argument.

  --contentroot=/content-root-path
  

Základ cesty

--pathbaseArgument nastaví základní cestu aplikace pro aplikaci spouštěnou místně s nekořenovou cestou relativní adresy URL ( <base> značka href je nastavená na jinou cestu než / pro pracovní a produkční). V následujících příkladech /relative-URL-path je základ cesty aplikace. Další informace najdete v tématu základní cesta k aplikaci.

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

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

• přidejte položku do launchSettings.json souboru aplikace v profilu IIS Express . toto nastavení se používá při spuštění aplikace s ladicím programem Visual Studio a z příkazového řádku s dotnet run .

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

• v Visual Studio zadejte argument v části vlastnosti > ladit > argumenty aplikace. nastavení argumentu na stránce vlastností Visual Studio přidá do launchSettings.json souboru argument.

  --pathbase=/relative-URL-path
  

Adresy URL

--urlsArgument nastaví IP adresy nebo adresy hostitelů s porty a protokoly, které se mají na požadavky naslouchat.

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

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

• přidejte položku do launchSettings.json souboru aplikace v profilu IIS Express . toto nastavení se používá při spuštění aplikace s ladicím programem Visual Studio a z příkazového řádku s dotnet run .

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

• v Visual Studio zadejte argument v části vlastnosti > ladit > argumenty aplikace. nastavení argumentu na stránce vlastností Visual Studio přidá do launchSettings.json souboru argument.

  --urls=http://127.0.0.1:0
  

Konfigurace Linkeru

Blazor provede propojení s mezijazykem (IL) na každém sestavení vydaných verzí a odebere z výstupních sestavení zbytečné IL. Další informace naleznete v tématu Konfigurace linkeru pro ASP.NET Core Blazor.

Změna přípony filename souborů DLL

V případě, že potřebujete změnit příponu filename pro publikované .dll soubory aplikace, postupujte podle pokynů v této části.

po publikování aplikace použijte skript prostředí nebo DevOps kanál sestavení pro přejmenování .dll souborů tak, aby používaly jinou příponu souboru. Zaměřte se na .dll soubory v wwwroot adresáři publikovaného výstupu aplikace (například {CONTENT ROOT}/bin/Release/netstandard2.1/publish/wwwroot ).

V následujících příkladech .dll jsou soubory přejmenovány, aby používaly .bin příponu souboru.

Ve Windows:

dir .\_framework\_bin | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content .\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content .\_framework\blazor.boot.json

Pokud se také používají prostředky pracovního procesu služby, přidejte následující příkaz:

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

V systému Linux nebo macOS:

for f in _framework/_bin/*; do mv "$f" "`echo $f | sed -e 's/\.dll/.bin/g'`"; done
sed -i 's/\.dll"/.bin"/g' _framework/blazor.boot.json

Pokud se také používají prostředky pracovního procesu služby, přidejte následující příkaz:

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

Chcete-li použít jinou příponu souboru než .bin , nahraďte .bin v předchozích příkazech.

Pro vyřešení komprimovaných blazor.boot.json.gz blazor.boot.json.br souborů proveďte jednu z následujících přístupů:

• Odeberte komprimované blazor.boot.json.gz soubory a blazor.boot.json.br . Komprese je u tohoto přístupu zakázána.
• Opětovná komprimace aktualizovaného blazor.boot.json souboru.

Předchozí pokyny platí i v případě, že se aktivují prostředky pracovního procesu. Odeberte nebo znovu proveďte komprimaci wwwroot/service-worker-assets.js.br a wwwroot/service-worker-assets.js.gz . V opačném případě kontroly integrity souborů selžou v prohlížeči.

následující příklad Windows používá skript prostředí PowerShell umístěný v kořenovém adresáři projektu.

ChangeDLLExtensions.ps1::

param([string]$filepath,[string]$tfm)
dir $filepath\bin\Release\$tfm\wwwroot\_framework\_bin | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content $filepath\bin\Release\$tfm\wwwroot\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\wwwroot\_framework\blazor.boot.json
Remove-Item $filepath\bin\Release\$tfm\wwwroot\_framework\blazor.boot.json.gz

Pokud se také používají prostředky pracovního procesu služby, přidejte následující příkaz:

((Get-Content $filepath\bin\Release\$tfm\wwwroot\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\wwwroot\service-worker-assets.js

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

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

Vyřešit selhání kontroly integrity

Při Blazor WebAssembly stažení spouštěcích souborů aplikace instruuje prohlížeč, aby prováděl kontroly integrity na odpovědích. Používá informace v blazor.boot.json souboru k určení očekávaných hodnot hash SHA-256 pro .dll , .wasm a dalších souborů. To je užitečné z následujících důvodů:

• Zajišťuje neriziku načtení nekonzistentní sady souborů, například pokud se na váš webový server použije nové nasazení, zatímco uživatel právě stahuje soubory aplikace. Nekonzistentní soubory mohou vést k nedefinovanému chování.
• To zajišťuje, že prohlížeč uživatele nikdy neukládá do mezipaměti nekonzistentní ani neplatné odpovědi, což by mohlo zabránit spuštění aplikace i v případě, že stránku ručně aktualizují.
• Umožňuje bezpečné ukládání odpovědí do mezipaměti a dokonce i kontrolu nad změnami na straně serveru, dokud se nezmění očekávaná hodnota hash SHA-256, takže následné načtení stránky zahrnuje méně požadavků a dokončí mnohem rychleji.

Pokud váš 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 v prohlížeči chybová zpráva podobná následující:

Nepovedlo se najít platný výtah v atributu integrity pro prostředek https://myapp.example.com/\_framework/My BlazorApp.dll s vypočtenou integritou SHA-256 IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY =. Prostředek je zablokovaný.

Ve většině případů to není problém s kontrolou integrity samotnou. Místo toho znamená, že došlo k nějakému problému a kontrola integrity vás upozorní na tento jiný problém.

Diagnostikování problémů s integritou

Při sestavení aplikace vygenerovaný blazor.boot.json manifest popisuje hodnoty hash SHA-256 svých spouštěcích prostředků (například,, .dll .wasm a dalších souborů) v době, kdy je vytvořen výstup sestavení. Kontrola integrity projde, dokud hodnoty hash SHA-256 ve blazor.boot.json shodě se soubory doručenými do prohlížeče.

Běžné důvody, proč se tato chyba nezdařila:

• Odpověď webového serveru je chyba (například Chyba 404-nenalezena nebo 500-interní chyba serveru) místo souboru, který prohlížeč požadoval. Prohlížeč tuto zprávu oznamuje jako selhání kontroly integrity a ne jako odpověď.
• Něco změnilo obsah souborů mezi sestavením a doručením souborů do prohlížeče. K tomu může dojít:
  • Pokud vytváříte nebo vytváříte nástroje, můžete výstup sestavení ručně změnit.
  • Pokud nějaký aspekt procesu nasazení změnil soubory. například pokud používáte mechanizmus pro nasazení na základě gitu, pamatujte, že Git transparentně převede konce řádků Windows stylu na konce řádků ve stylu Unix, pokud potvrdíte soubory v Windows a vrátíte se na Linux. Změna konců řádků souboru mění hodnoty hash SHA-256. Chcete-li se tomuto problému vyhnout, zvažte použití .gitattributes pro považovat artefakty sestavení jako binary soubory.
  • Webový server upraví obsah souboru v rámci obsluhy. Například některé sítě pro distribuci obsahu (sítě CDN) se automaticky pokusí minimalizuje HTML, takže se upraví. Tyto funkce možná budete muset zakázat.

Postup diagnostiky, které z těchto případů platí:

1. Všimněte si, že soubor spouští chybu načtením chybové zprávy.
2. Otevřete vývojářské nástroje v prohlížeči 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í. Vyhledejte soubor, který aktivuje chybu v tomto seznamu.
3. V odpovědi ověřte stavový kód protokolu HTTP. Pokud server vrátí jinou hodnotu než 200-OK (nebo jiný stavový kód 2xx), budete mít problém s diagnostikou na straně serveru. Například stavový kód 403 znamená problém s autorizací, zatímco stavový kód 500 znamená, že se server nedaří nespecifikovaným způsobem. Diagnostikujte a opravte aplikaci v protokolech na straně serveru.
4. Pokud je stavový kód 200 – OK pro prostředek, podívejte se na obsah odpovědi v vývojářských nástrojích prohlížeče a zkontrolujte, jestli se obsah shoduje s očekávanými daty. Běžným problémem je například nesprávně nakonfigurovaná směrování, takže požadavky vrátí 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. V takovém případě máte k diagnostice problém s směrováním na straně serveru.
5. V tématu řešení potíží s integritou skriptu PowerShelluse můžete pokusit ověřit publikovaný a nasazený výstup aplikace.

Pokud potvrdíte, že server vrací plausibly správná data, musí být něco jiného, než je třeba upravit obsah mezi sestavením a doručením souboru. Postup pro prošetření:

• Projděte si mechanismus sestavení sada nástrojů and Deployment v případě, že upravujete soubory po sestavení souborů. Příkladem je, že Git transformuje konce řádků souboru, jak je popsáno výše.
• v případě, že jsou nastavené tak, aby dynamicky měnily odpovědi (například pokus o minimalizuje HTML), prověřte webový server nebo konfiguraci CDN. Pro webový server je to pro implementaci komprese HTTP nutné content-encoding: br content-encoding: gzip , protože to neovlivní výsledek po dekompresi. U webového serveru ale není dobré upravovat nekomprimovaná data.

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

integrity.ps1K ověření publikované a nasazené aplikace použijte skript prostředí PowerShell Blazor . Skript se poskytuje pro PowerShell Core 6 jako výchozí bod, když má aplikace problémy s integritou, které Blazor Architektura nedokáže identifikovat. Pro vaše aplikace se může vyžadovat přizpůsobení skriptu, včetně toho, jestli běží na verzi PowerShellu novější než 6.2.7 verze.

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

• Změnili jste soubor v publikovaném výstupu, aniž byste ho museli realizovat.
• Aplikace nebyla správně nasazena do cíle nasazení nebo došlo ke změně v rámci prostředí cíle nasazení.
• Existují rozdíly mezi nasazenou aplikací a výstupem z publikování aplikace.

V příkazovém prostředí PowerShell volejte skript s následujícím příkazem:

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

Zástupné symboly

• {BASE URL}: Adresa URL nasazené aplikace.
• {PUBLISH OUTPUT FOLDER}: Cesta ke publish složce aplikace nebo umístění, 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ázat kontrolu integrity pro aplikace, které nejsou PWA

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

Můžou nastat případy, kdy se webový server nemůže spoléhat na to, že vrátí konzistentní odpovědi, a nemáte žádnou volbu, ale zakážete kontroly integrity. Chcete-li zakázat kontroly integrity, přidejte následující do skupiny vlastností v Blazor WebAssembly .csproj souboru projektu:

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResources také zakáže Blazor výchozí chování ukládání do mezipaměti .dll , .wasm a dalších souborů na základě jejich hash SHA-256, protože tato vlastnost označuje, že se na správnost nedají spoléhat hodnoty hash SHA-256. I s tímto nastavením může normální mezipaměť protokolu HTTP v prohlížeči pořád tyto soubory ukládat do mezipaměti, ale bez ohledu na to, jestli se k tomu dojde, závisí na konfiguraci webového serveru a na cache-control hlavičkách, které obsluhuje.

Zakázat kontrolu integrity pro PWAs

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ů aplikace pro použití v režimu offline. Jedná se o samostatný proces z normálního spouštěcího mechanismu aplikace a má svou vlastní samostatnou logiku kontroly integrity.

Uvnitř service-worker.published.js 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));

Opět se zakazováním kontroly integrity znamená, že ztratíte bezpečnostní záruky, které nabízí kontrola integrity. Například existuje riziko, že pokud je v prohlížeči uživatele mezipaměť aplikace do mezipaměti přesně v okamžiku, kdy nasazujete novou verzi, mohli byste ukládat do mezipaměti některé soubory ze starého nasazení a některé z nového nasazení. Pokud k tomu dojde, aplikace se zablokuje v nefunkčním stavu, dokud nenainstalujete další aktualizaci.