ASP.NET Core Blazor WebAssembly tárhely és üzembe helyezése

Ez a cikk bemutatja, hogyan üzemeltethet és helyezhet üzembe Blazor WebAssembly alkalmazásokat.

Blazor WebAssembly üzemeltetési modell esetén:

• A Blazor alkalmazás, annak függőségei és a .NET-futtatókörnyezet párhuzamosan lesz letöltve a böngészőbe.
• Az alkalmazás végrehajtása közvetlenül a böngésző felhasználói felületi szálán történik.

Ez a cikk arra az üzembehelyezési forgatókönyvre vonatkozik, amelyben a Blazor alkalmazás statikus üzemeltetési webkiszolgálóra vagy szolgáltatásra kerül, a .NET nem a Blazor alkalmazás kiszolgálására szolgál. Ez a stratégia az önálló üzembe helyezés szakaszában, valamint a csomópont egyéb, az IIS-hez, az Azure-szolgáltatásokhoz, az Apache-hoz, az Nginxhez és a GitHub Pageshez készült cikkeiben található.

Altartomány és IIS-alalkalmazás üzemeltetése

Az altartomány-üzemeltetéshez nincs szükség az alkalmazás speciális konfigurálásához. Nincs szükség az alkalmazás alap útvonalát (a címkéjét) konfigurálni az alkalmazás altartományban való elhelyezéséhez.

Az üzemeltető IIS-alalkalmazás megköveteli az alkalmazás alapelérési útvonalának beállítását. További információk és kereszthivatkozások az IIS al-alkalmazások üzemeltetésére vonatkozó további útmutatáshoz: ASP.NET Core tárhely és üzembe helyezés Blazor.

Egyes mobileszköz-böngészők maximális halomméretének csökkentése

Amikor egy az ügyfélen futó Blazor-alkalmazást hozunk létre (.Client projekt a Blazor Web App vagy önálló Blazor WebAssembly alkalmazás esetében) és a mobileszköz-böngészőket célozzuk meg, különösen az iOS-en futó Safarit, lehet, hogy szükség van az alkalmazás maximális memóriájának csökkentésére az MSBuild EmccMaximumHeapSize tulajdonságával. Az alapértelmezett érték 2 147 483 648 bájt, ami túl nagy lehet, és az alkalmazás összeomlik, ha az alkalmazás több memóriát próbál lefoglalni, és a böngésző nem adja meg. Az alábbi példa 268 435 456 bájtra állítja az értéket a Program fájlban:

<EmccMaximumHeapSize>268435456</EmccMaximumHeapSize>

A Mono/WebAssembly MSBuild tulajdonságairól és céljairól további információt a WasmApp.Common.targets (dotnet/runtime GitHub-adattár)című cikkben talál.

Webcil csomagolási formátum .NET-szerelvényekhez

Webcil a .NET-szerelvények webbarát csomagolási formátuma, amely lehetővé teszi a Blazor WebAssembly használatát korlátozó hálózati környezetekben. A Webcil-fájlok szabványos WebAssembly burkolót használnak, ahol a szerelvények WebAssembly fájlokként vannak üzembe helyezve, amelyek a standard .wasm fájlkiterjesztést használják.

A Webcil az alapértelmezett csomagolási formátum Blazor WebAssembly-alkalmazások közzétételekor. A Webcil használatának letiltásához állítsa be az alábbi MSBuild tulajdonságot az alkalmazás projektfájljában:

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

A rendszerindító erőforrások betöltésének testreszabása

Testre szabhatja a rendszerindító erőforrások betöltésének módját a loadBootResource API használatával. További információért lásd: ASP.NET Core Blazor indítási folyamat.

Compression

Egy Blazor WebAssembly-alkalmazás közzétételekor a kimenet statikusan tömörítve lesz a közzététel során az alkalmazás méretének csökkentése és a futásidejű tömörítés többletterhelésének eltávolítása érdekében. A rendszer a következő tömörítési algoritmusokat használja:

• Brotli (legmagasabb szint)
• Gzip

Blazor a szerverre támaszkodik a megfelelő tömörített fájlok kiszolgálásához. Ha Blazor WebAssembly önálló alkalmazást üzemeltet, további munkára lehet szükség a statikusan tömörített fájlok kézbesítésének biztosításához:

• Az IIS web.config tömörítési konfigurációjához tekintse meg a IIS: Brotli és Gzip tömörítési szakaszt.
• Ha olyan statikus üzemeltetési megoldásokon üzemeltet, amelyek nem támogatják a statikusan tömörített fájltartalom egyeztetését, fontolja meg az alkalmazás konfigurálását a Brotli-tömörített fájlok beolvasására és dekódolására:

Szerezze be a JavaScript Brotli dekódert a google/brotli GitHub-adattárból. A minifikált dekóder neve , és azadattár mappájában található.

Note

Ha a decode.js szkript (decode.min.js) minifikált verziója sikertelen, próbálkozzon helyette a nem meghatározott verzió (decode.js) használatával.

Frissítse az alkalmazást a dekóder használatára.

A(z) wwwroot/index.html fájlban a autostartfalse címkéjén állítsa a Blazor-t <script>-re:

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

A(z) Blazor<script> címkéje után és a záró </body> címke előtt adja hozzá a következő JavaScript-kód <script> blokkot. Az alábbi függvény meghívja fetchcache: 'no-cache', hogy a böngésző gyorsítótára frissüljön.

Blazor Web App:

<script type="module">
  import { BrotliDecode } from './decode.min.js';
  Blazor.start({
    webAssembly: {
      loadBootResource: function (type, name, defaultUri, integrity) {
        if (type !== 'dotnetjs' && location.hostname !== 'localhost' && type !== 'configuration' && type !== 'manifest') {
          return (async function () {
            const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
            if (!response.ok) {
              throw new Error(response.statusText);
            }
            const originalResponseBuffer = await response.arrayBuffer();
            const originalResponseArray = new Int8Array(originalResponseBuffer);
            const decompressedResponseArray = BrotliDecode(originalResponseArray);
            const contentType = type === 
              'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
            return new Response(decompressedResponseArray, 
              { headers: { 'content-type': contentType } });
          })();
        }
      }
    }
  });
</script>

Önálló Blazor WebAssembly:

<script type="module">
  import { BrotliDecode } from './decode.min.js';
  Blazor.start({
    loadBootResource: function (type, name, defaultUri, integrity) {
      if (type !== 'dotnetjs' && location.hostname !== 'localhost' && type !== 'configuration') {
        return (async function () {
          const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
          if (!response.ok) {
            throw new Error(response.statusText);
          }
          const originalResponseBuffer = await response.arrayBuffer();
          const originalResponseArray = new Int8Array(originalResponseBuffer);
          const decompressedResponseArray = BrotliDecode(originalResponseArray);
          const contentType = type === 
            'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
          return new Response(decompressedResponseArray, 
            { headers: { 'content-type': contentType } });
        })();
      }
    }
  });
</script>

A rendszerindító erőforrások betöltéséről további információt a ASP.NET Core Blazor indításicímű témakörben talál.

A tömörítés letiltásához adja hozzá az CompressionEnabled MSBuild tulajdonságot az alkalmazás projektfájljába, és állítsa az értéket false:

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

A CompressionEnabled tulajdonság a következő szintaxissal adható át a dotnet publish parancsnak egy parancshéjban:

dotnet publish -p:CompressionEnabled=false

URL-címek átírása a helyes útválasztáshoz

Az Blazor WebAssembly-alkalmazások lapösszetevőinek útválasztási kérései nem olyan egyszerűek, mint a Blazor Server-alkalmazások útválasztási kérelmei. Fontolja meg a két összetevőt tartalmazó Blazor WebAssembly alkalmazást:

• Main.razor: Betölt az alkalmazás kezdeti pontján, és tartalmaz egy linket a About összetevőre (href="About").
• Az About.razor: About összetevő.

Amikor az alkalmazás alapértelmezett dokumentumát kéri a böngésző címsorában (például https://www.contoso.com/):

1. A böngésző kérést küld.
2. A rendszer visszaadja az alapértelmezett lapot, amely általában index.html.
3. index.html indítsa el az alkalmazást.
4. Router összetevő betöltődik, és a RazorMain összetevő renderelődik.

A Főoldalon a About összetevőre mutató hivatkozás kiválasztása az ügyfélen működik, mert a Blazor útválasztó megakadályozza, hogy a böngésző kérést indítson az interneten www.contoso.comAbout számára, ehelyett maga szolgálja ki a renderelt About összetevőt. Az Blazor WebAssembly alkalmazáson belül belső végpontokra vonatkozó összes kérés ugyanúgy működik,: A kérések nem indítják el a böngészőalapú kéréseket a kiszolgáló által üzemeltetett erőforrásokra az interneten. Az útválasztó belső folyamatban kezeli a kéréseket.

Ha a kérés a böngésző www.contoso.com/Aboutcímsávjával történik, a kérés meghiúsul. Ilyen erőforrás nem létezik az alkalmazás internetes gazdagépén, ezért a rendszer egy 404 – Nem található választ ad vissza.

Mivel a böngészők az ügyféloldali lapokhoz az internetes szerverekre irányuló kéréseket továbbítanak, a webkiszolgálóknak és az üzemeltetési szolgáltatásoknak át kell irányítaniuk minden olyan erőforrásra vonatkozó kérést, amely fizikailag nincs a kiszolgálón, a index.html lapra. Amikor a index.html visszatér, az alkalmazás Blazor routere átveszi az irányítást és a megfelelő erőforrást biztosítja.

IIS-kiszolgálón való üzembe helyezéskor az URL-átírási modult az alkalmazás közzétett web.config fájljával használhatja. További információkért lásd: ASP.NET Core üzemeltetése és telepítése Blazor WebAssembly az IIS-szel.

Önálló üzembe helyezés

A önálló üzembe helyezés az Blazor WebAssembly alkalmazást statikus fájlok készleteként szolgálja ki, amelyeket az ügyfelek közvetlenül kérnek. Bármely statikus fájlkiszolgáló képes kiszolgálni a Blazor alkalmazást.

Az önálló üzembehelyezési eszközök a /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot vagy a bin/Release/{TARGET FRAMEWORK}/browser-wasm/publish mappába vannak közzétéve, ahol a {TARGET FRAMEWORK} helyőrző a célkeretrendszer.

Azure App Service

Blazor WebAssembly az alkalmazások üzembe helyezhetők az Azure App Servicesben Windows rendszeren, amely az alkalmazást IIS-en üzemelteti.

Az önálló Blazor WebAssembly-alkalmazások linuxos Azure App Service-ben való üzembe helyezése jelenleg nem támogatott. Azt javasoljuk, hogy az alkalmazást önállóan az Azure Static Web Appshasználatával helyezze el, amely támogatja ezt a forgatókönyvet.

Önálló alkalmazás Dockerrel

A különálló Blazor WebAssembly-alkalmazások statikus fájlok készleteként jelennek meg, amelyeket statikus fájlkiszolgálók üzemeltetnek.

Az alkalmazás üzemeltetéséhez a Dockerben:

• Válasszon egy Docker-tárolót webkiszolgáló-támogatással, például Nginx vagy Apache.
• Másolja a publish mappaegységeket a webkiszolgálón meghatározott helyre statikus fájlok kiszolgálásához.
• Szükség szerint további konfigurációt alkalmazhat a Blazor WebAssembly alkalmazás kiszolgálásához.

A konfigurációs útmutatásért tekintse meg a következő erőforrásokat:

• Nginx vagy Apache cikkek
• A Docker dokumentációja

Hoszt konfigurációs értékek

Az Blazor WebAssembly alkalmazások a következő gazdagépkonfigurációs értékeket elfogadhatják parancssori argumentumként futásidőben a fejlesztési környezetben.

Tartalomgyökér

A --contentroot argumentum az alkalmazás tartalomfájljait tartalmazó könyvtár abszolút elérési útját állítja be (tartalomgyökerű). Az alábbi példákban /content-root-path az alkalmazás tartalomgyökerének elérési útja.

• Adja át az argumentumot, amikor az alkalmazást helyileg futtatja egy parancssorban. Az alkalmazás könyvtárából hajtsa végre a következőt:

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

• Vegyen fel egy bejegyzést az alkalmazás launchSettings.json fájljára az IIS Express profilban. Ezt a beállítást akkor használja a rendszer, ha az alkalmazást a Visual Studio Hibakeresővel futtatja, és egy parancssorból dotnet watch (vagy dotnet run).

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

• A Visual Studióban adja meg az argumentumot Tulajdonságok>Hibakeresés>alkalmazásargumentumok. A Visual Studio tulajdonságlapjának argumentumának beállítása hozzáadja az argumentumot a launchSettings.json fájlhoz.

  --contentroot=/content-root-path
  

Elérési út alapja

A --pathbase argumentum beállítja a helyi futtatású alkalmazás alap elérési útját egy nem gyökérszintű relatív URL-címmel (a <base> címke href az előkészítéshez és az éles környezethez /-tól eltérő útvonalra van beállítva). Az alábbi példákban /relative-URL-path az alkalmazás elérésiút-alapja. További információ: ASP.NET Core-alkalmazás Blazor alap elérési útja.

Important

A href címke <base> megadott elérési úttól eltérően ne tartalmazzon záró perjelet (/) a --pathbase argumentumérték átadásakor. Ha az alkalmazás alap elérési útja a <base> címkében <base href="/CoolApp/"> ként van megadva (egy záró perjelet is tartalmaz), adja át a parancssori argumentum értékét --pathbase=/CoolApp (nincs záró perjel).

• Adja át az argumentumot, amikor az alkalmazást helyileg futtatja egy parancssorban. Az alkalmazás könyvtárából hajtsa végre a következőt:

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

• Vegyen fel egy bejegyzést az alkalmazás launchSettings.json fájljára az IIS Express profilban. Ez a beállítás akkor használatos, ha az alkalmazást a Visual Studio Hibakeresővel vagy egy parancssorból, mint dotnet watch (vagy dotnet run), futtatja.

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

• A Visual Studióban adja meg az argumentumot Tulajdonságok>Hibakeresés>alkalmazásargumentumok. A Visual Studio tulajdonságlapjának argumentumának beállítása hozzáadja az argumentumot a launchSettings.json fájlhoz.

  --pathbase=/relative-URL-path
  

További információ: ASP.NET Core-alkalmazás Blazor alap elérési útja.

URLs

A --urls argumentum az IP-címeket vagy gazdagépcímeket portokkal és protokollokkal állítja be, hogy figyeljék a kéréseket.

• Adja át az argumentumot, amikor az alkalmazást helyileg futtatja egy parancssorban. Az alkalmazás könyvtárából hajtsa végre a következőt:

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

• Vegyen fel egy bejegyzést az alkalmazás launchSettings.json fájljára az IIS Express profilban. Ez a beállítás akkor használatos, ha az alkalmazást a Visual Studio Hibakeresővel vagy egy parancssorból, mint dotnet watch (vagy dotnet run), futtatja.

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

• A Visual Studióban adja meg az argumentumot Tulajdonságok>Hibakeresés>alkalmazásargumentumok. A Visual Studio tulajdonságlapjának argumentumának beállítása hozzáadja az argumentumot a launchSettings.json fájlhoz.

  --urls=http://127.0.0.1:0
  

Trimmer konfigurálása

Blazor köztes nyelvi (IL) trimmelt hajt végre minden Release builden, hogy eltávolítsa a felesleges IL-t a kimeneti összeállításokból. További információt az ASP.NET Core-hoz készült trimmer konfigurálásáról című témakörben talál.

Az üzembe helyezés különféle hibái

Általában üzembe helyezéskor:

• A rendszer csak a módosított fájlokat cseréli le, ami általában gyorsabb üzembe helyezést eredményez.
• Az új üzembe helyezés részét nem képező meglévő fájlok megmaradnak az új üzembe helyezéshez.

Ritka esetekben egy korábbi üzembe helyezésből hátramaradt fájlok tönkretehetik az új üzembe helyezést. A meglévő üzembe helyezés teljes törlése (vagy a helyileg közzétett alkalmazás az üzembe helyezés előtt) megoldhatja a sérült üzembe helyezéssel kapcsolatos problémát. A meglévő üzembe helyezés törlése gyakran elegendő egyszer a probléma megoldásához, beleértve a DevOps építési és telepítési folyamatát is.

Ha úgy ítéli meg, hogy a DevOps buildelési és üzembe helyezési folyamat használatakor mindig szükség van egy korábbi üzembe helyezés törlésére, ideiglenesen hozzáadhat egy lépést a buildelési folyamathoz, hogy törölje az egyes új telepítések korábbi üzembe helyezését, amíg meg nem hárítja a sérülés pontos okát.